前端架构设计：层次设计
我们在开发的不同阶段，构成的架构因素是不同的，基于这个思路，架构可以分为：
- 系统级架构
- 应用级架构
- 模块级架构
- 代码级架构
系统级架构
应用在整个系统内的关系，如与后台服务如何通信，与第三方系统如何集成。在设计前端的时候，首先应该考虑的，是前端系统与其他系统之间是怎样的关系。
这种关系包含，业务关系和协作机制，比如与其他前端应用之间，如何进行交互和通信。如何与后台对接实现权限，授权，api管理等功能。
如果与后台通信，只需要规定与后台数据传递的机制即可，包括api设计规则，访问授权的一个开放标准（OAuth）跳转token的验证，数据传递cookie等。对于前端与后端的关系，我们所考虑的主要因素是前后端分离的架构设计。
前后端分离架构其实是如何实施技术决策，用户鉴权、API接口管理和设计、API文档管理、Mock的使用、BFF(服务于前端的后端，nodejs)，是否需要服务端渲染等。所有以上决策，都需要不同团队，比如前端与后端，与产品需求分析师，与测试的不断沟通，才能一起设计出整个系统方案。
而微前端很微妙，在一个系统内微前端是应用间的架构方案；在多个应用之间，微前端则是一种系统间等架构方案。微前端是将多个前端应用以某种形式结合在一起进行应用。下面我们来深入了解一下，微前端。
微前端的几个核心价值
- 与技术栈无关。主框架不限制接入应用的技术栈，子应用具备完全自主权
- 独立开发、独立部署。子应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新
- 独立运行时，每个子应用之间状态隔离，运行时状态不共享 其实可以这样理解，微前端，是类似前后端分离的形态。
微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用(Frontend Monolith)后，随之而来的应用不可维护的问题。
这类问题在企业级 Web 应用中尤其常见，比如淘宝。阿里这么大的体系，淘宝，天猫，支付宝，一淘，淘票票，阿里云，都可以用同一个账号登陆，他们前端部分就是用的微前端，登陆这块就是一个微前端模块。
还比如，之前我负责开发大屏系统，里面的角色权限控制模块可以独立成一个微前端，通过路由连接主系统；我们在孔雀屏系统配置好大屏页面，获得一个URL地址，将地址用类似iframe的方式放到系统页面里面展现。这其实就是一个比较简单的微前端解决方案。
这块架构的难点，在于主系统与各个子应用的连接方式，模块导入，子应用暴露钩子，路由配置，应用和样式隔离，js隔离，跨域等问题的解决方案。
微前端两种形式
- 单实例：即同一时刻，只有一个子应用被展示，子应用具备一个完整的应用生命周期。通常基于 url 的变化来做子应用的切换。
- 多实例：同一时刻可展示多个子应用。通常使用 Web Components 方案来做子应用封装，子应用更像是一个业务组件而不是应用。
应用级架构
应用级架构可以看作是系统级架构的细化，比如单个应用与其他外部应用的关系，微服务架构下多个应用的协作，数据交换等。 由于各个应用之间，需要通过复用代码，共享组件库，统一设计等减少工作量，因此，微妙要考虑以下几个方面内容：
- 脚手架。看我另一篇文章前端脚手架CLI生成模版命令工具（包括，npm包的发布，脚手架的搭建，注意事项，优化等）作为一个基础等模块应用，脚手架用于快速生成搭建前端应用。它除了包含一个前端项目所需等要素，还包含组织内部相关等规范和模式，如部署模版，构建系统等。一个CLI应用可以支持多个应用等开发，能根本的提高团队整体的工作效率。
- 模式库。它是一系列可复用代码合集，如前端组件，通用工具函数等，带业务或不带业务的组件。作用是多个应用之间共享代码，降低修改成本。模式库，有的只涉及UI层面，比如antd；有的涉及业务，有的可以封装通用接口，有的包含多个应用通信数据库，这个就需要多方统一协作沟通，最终目的就是提高工作效率，降低开发和维护成本。
- 设计系统。这个主要偏向设计人员模式，而非开发人员视角。需要UI有更高的视野，才能设计出有高度统一标准的UI规范。
模块级架构
这部分内容是我们开始业务编码之前进行设计，我们成为迭代0，相关内容有两方面：
- 模块化。包含css,js,html的模块化。js受框架的影响比较大（vue还是react）；css我们需要设计一个合理的方式进行管理，比如全局样式的复用（antd global样式），局部样式用于隔离，通用变量方便修改（主题色）；还需要定义js，css，html代码的组织方式。
- 组件化主要考虑，如何对组件进行封装，以及组件拆分原则和粒度（考虑复用性）。
代码级架构：规范与原则
真正实际操作写代码的时候，主要考虑以下几个问题：
- 开发流程。代码管理方式，合并方式，分支管理，提交规范，测试规范等。
- 代码质量以及改善。开发过程中，代码注重整洁，以及测试驱动开发（TDD）。注意测试策略，测试目的不是减少bug，而是用测试验证现有的功能是正确的。
- 规范而非默契。代码风格统一，使用几个空格，文件的命名等规范。
此外，在开发中，还要注意可维护性，简单的代码可维护性高，更容易读懂和维护。越是写的抽象的代码越难维护。比如前端的hook，有的人滥用，没用好很难维护。
以上就是根据开发的不同阶段，需要思考的四个不同层级的架构。
