架构是体现在它的组件中的一个系统的基本组织、它们彼此的关系、与环境的关系及指导它的设计和发展的原则。—— IEEE (1471 2000)

1.1. 设计架构的层次要素（架构金字塔）

为此，我们划定了架构的四个层级 + 基础设施层：

• 系统级，即整个系统内各部分的关系，诸如于如何通讯，以及如何与第三方系统如何集成等。
• 应用级，即单个应用的整体架构，及其与系统内单个应用的关系等。
• 模块级，即应用内部的模块架构，如代码的模块化、数据和状态的管理等。
• 代码级，即从代码级别保障架构实施。

注：图中的服务导向架构出自于《演进式架构》，包含了 SOA、微服务架构及基于服务的架构等；而聚合导向架构指的则是客户端的架构模式，客户端以聚合来展示一致性，诸如前端领域的微前端、移动应用的插件化等。

这种架构模式，特定符合我们日常设计架构的特点： 先自顶向下设计，再自底向上实践 （适应）。

1.1.1. 先自顶向下设计

架构的设计模式，让人不禁联想到设计领域里 Design System 之中的 Atomic Design。原子设计是一个设计方法论，由五种不同的阶段组合，它们协同工作，以创建一个有层次、计划性的方式来界面系统。

相似的，我们将其中的生物模型与我们的金字塔架构做一层映射，就得到了我们所需要的架构层次模型：

• 原子级 <-> 代码
• 分子级 <-> 模块/组件
• 组织级 <-> 应用
• 有机体 <-> 系统

1.1.2. 再自底向上适应

当我们划定了四层架构之后，我们会发现大部分软件系统的设计有出现一定的问题——只设计了 顶层架构 ，缺少了代码级别（原子级别）的基础适应度函数的设计。（PS：对于小型 IT 团队来说，它们还缺乏基础设施。）

即，为了保护整个系统的架构不被破坏，我们还需要：

• 代码整洁规范。
• 设计原则与设计模式。注意，这里的设计模式，并非单单指 23 种设计模式，而是模式的总称。

1.2. 高度自动化的工作流

工作流（Workflow），是对工作流程及其各操作步骤之间业务规则的抽象、概括描述。

1.2.1. 开发工作流自动化

对于一个技术先进的组织来说，一个新的项目成员来到这个项目时：

• ta 的开发机器应该能执行一个或者多个脚本，便能完成开发系统的初始化。
• ta 的开发环境应该能执行一个或者多个脚本，便能完成开发环境的设备。
• ta 的开发环境应该能执行一个或者多个脚本，便能运行起来。
• ta 的代码提交到版本管理服务器时，便能完成自动部署到测试环境。

如果做不到自动化，那么就可视化。

1.2.2. 风格受限的规范实践

除此，在这些工作流中，我们还会穿插一些代码规范：

• 提交 Hooks，诸如于 prepush 或者是 precommit 等
• 代码风格自动审查（Lint）。
• 函数式的规范化。
• 提交信息格式。
• 命名规范。

1.3. 完善工具与基础设施

适合的工具与基础设施，能极大地提升系统的开发效率。也是软件体系开发中非常重要的一环。

对于小型 IT 团队来说，选择适合的工具和基础设施，是一件非常困难的事情。它受限于团队的经验和能力，以及其在市场上很能招聘到的新成员。

对于大型 IT 团队来说，开发适用于组织的开发工具、基础设施都是一笔非常划算的买卖。

1.4. 更好的知识传递

知识传递，是指以交流和继承认识成果，取得间接经验的一种教育形式。

在设计架构和系统的时候，我们务必要考虑其在整个系统中的实施。毕竟知识传递的速度，是限制一家公司发展的关键因素之一。。在日常的软件开发中，常见的知识传递的方式有：

• 文档。
• 代码检视。
• 日常站会。
• 结对编程 。
• 测试用例。好的测试用例可以直接体现业务逻辑，而不需要多余的解释。

我们最常遭遇的一个是陷阱：不及时更新、滞后、无效的文档。

1.4.1. 不止于代码的代码检视

代码检视（Code Review）是一个非常有效的知识方式，比它更有效的恐怕就是结对编程了。但是，人们一直忽略了代码检视的一个重要内涵， 知识传递 。如果你在代码检视（Code Review）的时候，有任何上下文相关的业务问题、技术问题，那么你应该提出来，而其它团队成员也应该帮你解决这个问题。

1.4.2. 组件设计原则

• 基础组件库，如 Material Design
• 二次封装组件。额外的三方组件库，如 Infinite Scroller，务必在封装后使用。
• 自制基础组件。
• 领域特定组件。

上述的四部分，构建了整个系统的通用组件库模块。随后，便是业务相关组件和页面级组件。

• 业务相关组件。在不同的模块、页面之间，共享逻辑的组件。
• 页面级组件。在不同的模块、路由之间，共享页面。