来看看你离前端架构师还有多远？大型前端应用架构设计提纲

哈鲁，我又来了。最近在知乎上有点郁闷，同一个帖子，赞的多骂的也多。原委大致是讨论为什么某v*框架不适合构建大型项目，反正带节奏的人只要三五个字，就有一众人在下面跪舔。今天来聊一聊我的观点：无论是v*还是rea*，都只是大型前端应用中很小的一部分，并不具备完全的不可替代性，讨论完全基于该框架来构建大型项目，是欠妥的。

命题里面最关键的词是“大型”，但凡参与过大型前端应用开发的朋友，都不限于把思维限定在完全基于某个框架的开发。当然，现代前端框架还是有局部的决定作用，一旦技术选型，那么就不得不按照它的编程范式，引入其生态的第三方工具。但是，对于构建“大型”应用而言，更重要的在于架构。可以说架构的好坏，决定了该项目在未来几年中的实际运维成本。而没有参与过大型应用开发的同学，不应该用单体应用的思维以偏概全的设计将要实施的应用。

那么，作为已经有一定经验的前端工程师，你应该如何去思考和设计大型的前端应用呢？接下来，我把自己认知范围内的大型企业应用前端架构设计概要列出来，仅供你参考。纲要如下：

以上只是我想到的架构设计的方面啦，欢迎在下方留言补充～

在我看来，设计大型企业应用前端架构的最核心两方面，在于设计应用的结构和解决业务的复杂性。这两个方面是我认为的重中之重，是具有宏观层面的一览众山小的前置要领。在所有工作之前，不对这两个核心点进行回答，后面所做的所有工作，都会白费，或者都会消耗大量时间精力后反复重来。

应用的结构

或者说应用架构，是从程序的执行层面去看，这个应用怎么启动，怎么让各个部分协调工作，由此引申出来的是，怎么设计才能保证庞大且复杂的业务操作在我的程序运行过程中、开发过程中、设计过程中，不出错。一旦一个应用涉及的业务方面特别多，层次特别深时，其复杂度及难度都是指数级上升。解决的办法，就是我们常说的“解耦”，把庞大的体系拆分开来，把那些不需要依赖于另外一些内容的部分独立出来，我虽然不能保证我这个庞大的系统没有错误，但是我起码能保证在这个局部的系统里，我可以尽可能做到最好，至于后面怎么融合到整套系统中，我可以后面慢慢打磨。就是这么一个思路。符合这一思路的前端架构方案就是微前端，当然，这里的微前端跟微前端框架是两回事，不少人一谈到微前端，马上就某*kun啦巴拉巴拉。通过微前端的架构，我们可以让我们的业务按照一定的边界进行划分，在设计、管理、开发、运维等方面，都可以具有较强的独立性，从而保证一定的自治，实现在庞大的开发体系中，做到有条不紊，循序渐进。

业务的设计

或者说业务架构，是从实现具体需求的角度出发，这个应用的代码层次应该怎么去布局，怎么让业务逻辑、领域对象、业务流转能够更加清晰，避免一个业务反复写，到处写，乱调用，乱实现。在很多前端项目中，项目的设计者（甚至很多项目没有架构）可能根本没考虑这些问题，一上来就是一把梭撸，而没有深刻思考这种业务层面的东西它在代码层次中怎么布局，全凭意识流，写到哪里算哪里。解决的办法就是我们常说的“抽象”，把一个一个的业务梳理出来，用代码表达出来。比如一个财务系统，我要管理资金从哪里来，到哪里去，每一笔钱在流动时都在做什么事，这个事有些什么维度和度量。听上去这好像是后端建模和建库的事。在前端，你也得去做这件事，你得梳理出你负责的业务，并且用代码表达出来，梳理不出业务，你就是在瞎折腾，平日里没啥事，真正遇到问题的时候，一个数据对不上你就哦豁面临毕业风险。这里，我借助DDD的思想，用UML去梳理业务，用建模去抽象化业务，通过分层架构搭建从领域层到应用层的完整前端层次体系。这部分内容，可以阅读我之前发过的文章《复杂企业应用前端架构探索》。其实很多东西，讲来讲去，思想都是不变的。

Ops vs. 规范

人是围绕项目转的，返回来，项目也围绕着人在转。每个人每天工作8小时（^_^想的美