【架构设计02】C4架构模型

提到架构设计时，我们能想到无数的方框，圆框，不同颜色标注的模块，专业术语，各种形状的线条和箭头。我们还用用UML统一建模语言用于专业的架构程序设计。但扪心自问UML真的是一种高效简洁的设计方案吗？不是的，他就想五笔打字输入一样，在20年前是一种IT形象的代言，而如今已经被束之高阁，被更加简洁的输入法替代。很多团队还没有找到更好的替代品，在团队为了“效率”选择不做设计文档——从而丧失了团队高效沟通的重要手段。

C4架构设计模型是一种容易学习，适用范围很广，能够让大多数刚入门工程师进行高效可视化文档设计的手段。今天就给大家介绍这种架构方法：

当我们打算去一个陌生的地方旅游时，我们会习惯性打开地图查看周边的情况。

我们可以通过实景查看具体的街道位置走向，了解最底层的信息 也可以放大地图查看周边的情况

也可以放大地图看目标地址周围有哪些区域 总之，我们可以通过扩大和缩小的方式，让地图展示不同层面的信息，具体的维度取决于关注想要了解的信息 层面。C4模型基本实现和上面类似，只是将架构设计整体抽象成为了四个大的层面。

C4架构设计是一个通过架构图来描述程序流程和架构设计的方法论，它最强大的地方在于仅仅通过四个模型就可以完成绝大部分系统的设计。

C4设计模型的核心理念是“抽象”和“放大”，通过抽象的设计体现对开发者打算如何构建我们的系统和程序。通过抽象的组合组成了完整的系统架构设计。这种抽象维度可以放大展开细节或者缩小隐藏细节，学习过程轻松简单，效果直观，是开发设计的利器。 注：后面我会替换成中文的版本

画图步骤：

设计要点： 5. 忽略细节，能看出整体即可。 6. 重点关注关联用户、角色、系统、服务等，详细的内容无需描述。 7. C1模型面向的是非技术人员。所以不要标注编程术语、网络协议等专业用词。

容器虽然是C1模型中目标系统的放大，但仍是一种较高层次的抽象。官方给的解释是，web容器，比如serverlet 容器，单页面服务，APP，文件系统等。实际过程中，我们可能设计是容器本身，比如一个文件系统，可能无法向下划分出子容器。我们需要灵活应变，只需要理解为对C1的放大即可。

画图步骤

设计要点： 4. 不需要标注部署相关的信息，比如集群模式、副本数量，容灾能力等。这些都不是本阶段的重点。 5. 面向略懂技术或者技术团队内部，可以有适当的技术描述。 6. 每个容器必须是独立可运行的组件，独立发布部署的。从较高的层面支出系统的组成的子系统和组件服务。

和容器一样需要先理解组件是那种层面的抽象，这里组件其实已经到了代码文件级别，可以理解为我们已经设计好了代码的文件名称，并没有打开具体的文档查看代码。

画图步骤

设计要点：

顾名思义代码级别的设计，用于直接指导具体的代码逻辑。例如：类图，设计模式

设计步骤： 没有固定的步骤，或者说是一门专门的理论。可以参考UML制图的专项学习。

设计要点： 说明代码中类、接口、注解、聚合关系，设计模式、强弱引用，引用方向等等。设计的好坏直接决定的代码的易用性和可扩展性。

这个级别是否要出设计图是存在争议的。Brooks在其著作《人月神话》中直接了当的批评了人工设计UML类图的方法。这种方式需要耗费不少的人力成本，推荐采用代码生成设计的方式，利用自动化生成工具来完成。

C4 模型能够对系统设计进行完整和而清晰的描述，我们在掌握C4架构设计模型的基础上可以通过其他图谱类提供不同的设计视角，来进一步提供设计的其他信息。我们只需要关注图谱的缩放层级即可。

C1 模型描述了单个系统和其他系统的关系。真实世界中，我们可能需要同时提供多个系统的说明。系统鸟瞰图和C1的基本一致，只是单纯增加更多的系统。只要掌握了C1的画法，多加几个系统即可。

其实就是UML图中的动态行为图，下图和UML中的写作协作图完全一致。只是提供了一种新的参考。用来描述组件和组件之间数据交互流程和协作关系。

顾名思义主动表述组件的部署架构，包括节点数量，容灾模式，技术选型，数据副本等。这个在UML图中也有，不必特殊对待。

首先说明，工具不重要，你可以直接使用一张白纸来完成。 只推荐一个，不是说最好的，而是可以被所有读者考虑的选择。draw.io 免费开源，不受网络限制。