前端有架构吗？前端有架构模式吗？

架构是什么？

软件架构，是一种为了解决复杂问题的通用模式。软件架构，是关于软件系统的一系列有层次的技术决策的集合。换句话来说，当我们讨论架构的时候，不能只讨论某某架构，而是要包含其实施，以及后期的维护。

因为：

• 一个无法上线的应用架构，算不上是好的软件架构
• 一个没有人能完成开发的软件架构，算不上是可行的软件架构
• 一个在现有的技术上不可行的架构，算不上是合理的软件架构

诸如微服务，对于复杂的后端系统来说，是一种不错的『低耦合，高内聚』的实施。但是，它并不适合于大部分的小公司——复杂的架构不适合于简单的应用。而小公司也缺乏足够的人才，来实施一个复杂的系统，与此同时还需要有人能维护这个系统。

所以，当我们谈及软件架构的时候，说的是：有这么一些人，他/她们能按时、高质量（或者说有质量）完成这一个系统的设计——即有能力的个人。

PS：对于前端架构来说，这些人大概率会来自于看了本书的人，笑~

前端架构拆解：四层次设计

从笔者的角度来看，架构设计本身是分层级的，面向不同级别的人时，所展示的内容也是不一样的。如面对的是同一级别、更高一级别的架构师、技术人员，说的便是形而上学的东西，如微前端、前后端分离，并通过各种概念，如构建系统拆份，以抽象的方式介绍如何去设计。这些概念，对于接触过的程序员来说，也是相当好理解的。而当我们面对的是，经验略微丰富的程序员的时候，说的可就不是：去实现微前端这样的东西。而是需要落实到怎样去做这样的一件事。

在不同的时期，不同的阶段，我们考虑的架构相关的因素是不同的。按照这个思想，笔者将架构的设计分为了四个层级：

系统级，即应用在整个系统内的关系，如与后台服务如何通讯，与第三方系统如何集成。 应用级，即应用外部的整体架构，如多个应用之间如何共享组件、如何通信等。 模块级，即应用内部的模块架构，如代码的模块化、数据和状态的管理等。 代码级，即从基础设施来保障架构实施。

对应的层级与实施模式，如下图所示：

系统内架构

在设计前端架构的时候，首先考虑的是应用在整个系统中的位置——它与系统中的其它子系统是怎样的。这种关系包含了架构上的关系、业务上的关系，以及它们之间的协作机制。对于前端应用来说，这一部分的子系统包含了：

• 其它前端应用。侧重于关注如何与这些应用交互，诸如交互、通讯等。
• 对接的后台服务。关注于如何与后台服务进行通信，诸如权限、授权、API 管理等。

若是系统间的数据通信，如与后台服务之间的交互，那么只需要规定好数据通信、数据传递的机制即可。这一类的通讯机制，不仅仅包含了前后端分离架构的 API 设计，还包含了各类的数据传递，诸如 OAuth 跳转的 Token 验证。除此，对于传统的多页面应用来说，也需要关注于其中的数据传递，如 Cookie 作为用户凭据等等。

为此，对于前端开发人员来说，关于与后端间的关系，我们所要考虑的主要因素是前后端分离架构的设计。

• 前后端分离架构。（详见《前端架构：从入门到微前端》）
• 微前端架构。（详见《前端架构：从入门到微前端》）

而后，我们还需要考虑到前端的客户端展现形式。在大前端的背景之下，它可能是以 PC Web 应用、移动 Web 应用、混合移动应用（结合 Cordova 构架）、混合桌面应用（结合 Electron 框架）、原生移动应用（结合 React Native）等，具体选择何一种技术，取决于我们在之前调查的利益相关者的需求。

当我们做完上述的三个核心的架构决策之后，就需要考虑一下应用的部署架构。不同的客户端形式，或者需要服务端渲染，会在某种程度上影响到前端应用的部署，但是总的影响并不是太大。往往只需要通过反向代理的配置，就可以完成部署的配置。若是与后台服务不在一个域，则需要考虑支持跨域请求或者是后台做一层代码。

在有了这些基本的架构设定，便可以往下继续设计下一层级的应用架构。

应用级架构

应用级架构，指的是单个应用与外部应用的关系，如微服务架构下的多个应用的协作。它可以是一个团队下的多个前端应用，又或者是一个组织内的前端应用。其在组织中所处的位置，也进一步决定了我们所需要设计的架构方案。

若是从相关的定义上来看，它与系统级应用存在一定的交集。但是，笔者将其视之为系统级架构的进一步细化。如在系统内架构的层级里，我们定义了微前端架构，而具体的实施细则会放在各个应用中实现的。而诸如应用间的数据如何交换，而不同的应用又有各自不同的实现，则会在这个层级里定义了相应的接口。

与此同时，当我们维护了多个前端应用，必然会去考虑在这些应用之间，复用代码、共享组件库、统一设计等，以减少相应的工作量。为此，在这个层级里，我们会考虑下面的一些架构相关的设计内容：

• 脚手架。（详见《前端架构：从入门到微前端》）
• 模式库。（详见《前端架构：从入门到微前端》）
• 设计系统。（详见《前端架构：从入门到微前端》）

与此同时，在这个层级里，我们决定选择什么前端框架，进行相关的技术选型。

模块级架构

模块级架构，便是深入单个应用内部，更细致的设计应用内部的架构。它所涉及的部分，便是在日常开发中，我们经常接触到的主要部分。我们所做的便是制定一些规范，又或者是更细致的架构设计。这部分的内容，会在我们开始业务编码之前进行设计，在敏捷软件开发中，它称之为 迭代 0/Sprint 0/Iteration 0。相关的内容有：

• 模块化。（详见《前端架构：从入门到微前端》）
• 组件化。（详见《前端架构：从入门到微前端》）

除此，对于不同的框架，还涉及到一些框架特定的模式与架构设计，它们会在一定程度上影响单个应用的架构。对于不同的框架来说，所需要涉及的范围都有所不发。如在 Angular 框架中，不需要操心相关的模式，只需要掌握框架定义的规范即可，如使用 Service 来保存应用的状态，使用 Pipe 来处理数据等。而在 React 框架中，则需要设计状态和数据流的管理方式，为此便需要诸如 Flux 或者 Redux 这样的状态管理方案。

代码级：规范与原则

当我们真正编码的时候，考虑的架构因素便是更低层级的内容。这部分的架构设计，便称为代码级的架构设计，它关注于实践过程中的相关规范和原则。这部分的内容相当的多，并且繁琐。它包含了以下的内容，但是又不限于下述的部分：

• 开发流程。（详见《前端架构：从入门到微前端》）
• 代码质量及改善。（详见《前端架构：从入门到微前端》）
• 规范而非默契。（详见《前端架构：从入门到微前端》）

除此，在日常的开发中，还需要注重代码的可维护——简单的代码更容易读性和维护。笔者维护一个 Scala 项目的过程中，便是深有体会——越是写得越抽象的代码，越难以维护。诸如函数式编程是一个好的东西，但是好的东西也容易被烂用，导致人们不喜欢这个东西。

小结

买， 买，买

——节选自《前端架构：从入门到微前端》