【架构设计02】C4架构模型-四步完成绝大部分的设计
架构设计困境
提到架构设计时，我们能想到无数的方框，圆框，不同颜色标注的模块，专业术语，各种形状的线条和箭头。我们还用用UML统一建模语言用于专业的架构程序设计。但扪心自问UML真的是一种高效简洁的设计方案吗？不是的，他就想五笔打字输入一样，在20年前是一种IT形象的代言，而如今已经被束之高阁，被更加简洁的输入法替代。很多团队还没有找到更好的替代品，在团队为了“效率”选择不做设计文档——从而丧失了团队高效沟通的重要手段。
C4架构设计模型是一种容易学习，适用范围很广，能够让大多数刚入门工程师进行高效可视化文档设计的手段。今天就给大家介绍这种架构方法：
引言
当我们打算去一个陌生的地方旅游时，我们会习惯性打开地图查看周边的情况。
我们可以通过实景查看具体的街道位置走向，了解最底层的信息
也可以放大地图查看周边的情况
也可以放大地图看目标地址周围有哪些区域
总之，我们可以通过扩大和缩小的方式，让地图展示不同层面的信息，具体的维度取决于关注想要了解的信息 层面。C4模型基本实现和上面类似，只是将架构设计整体抽象成为了四个大的层面。
定义
C4架构设计是一个通过架构图来描述程序流程和架构设计的方法论，它最强大的地方在于仅仅通过四个模型就可以完成绝大部分系统的设计。
C4模型
- COTEXT上下文：高度抽象的系统层面描述系统之间的交互图谱，说明系统之间的差异性和联通情况
- CONTAINER：容器指的是应用层面，通过放大某个系统查看里面的应用组成
- COMPONENT: 放大某个应用我们能看到应用组件，这些组件对应了代码组件。能够成为描述应用组成的重要参考。
- CODE: 代码层面的设计，也就是类图等UML制图。描述了一本或者多本代码的设计思路，和类的关联。
C4设计模型的核心理念是“抽象”和“放大”，通过抽象的设计体现对开发者打算如何构建我们的系统和程序。通过抽象的组合组成了完整的系统架构设计。这种抽象维度可以放大展开细节或者缩小隐藏细节，学习过程轻松简单，效果直观，是开发设计的利器。
注：后面我会替换成中文的版本
C1 System Context系统上下文
画图步骤：
- 为目标系统画一个框，在周围画出和当前系统关联的用户和其他系统。
- 写上每个系统的名字，并附加每个系统的功能说明
- 添加系统之间的关系和说明。
- 目标系统使用亮色，关联系统可以使用暗色，让用户一眼看到重点。
设计要点：
5. 忽略细节，能看出整体即可。
6. 重点关注关联用户、角色、系统、服务等，详细的内容无需描述。
7. C1模型面向的是非技术人员。所以不要标注编程术语、网络协议等专业用词。
C2 Container 容器图谱
容器虽然是C1模型中目标系统的放大，但仍是一种较高层次的抽象。官方给的解释是，web容器，比如serverlet 容器，单页面服务，APP，文件系统等。实际过程中，我们可能设计是容器本身，比如一个文件系统，可能无法向下划分出子容器。我们需要灵活应变，只需要理解为对C1的放大即可。
画图步骤
- 复制C1模型的图谱准备放大目标系统（亮色标注部分）
- 画出目标系统内部设计的web组件，比如web页面、移动app、单页面应用、数据库、API接口等。
- 描述每个容器和外部系统的具体关联关系。
设计要点：
4. 不需要标注部署相关的信息，比如集群模式、副本数量，容灾能力等。这些都不是本阶段的重点。
5. 面向略懂技术或者技术团队内部，可以有适当的技术描述。
6. 每个容器必须是独立可运行的组件，独立发布部署的。从较高的层面支出系统的组成的子系统和组件服务。
C3 Compoent 组件
和容器一样需要先理解组件是那种层面的抽象，这里组件其实已经到了代码文件级别，可以理解为我们已经设计好了代码的文件名称，并没有打开具体的文档查看代码。
画图步骤
- 深刻理解需求的基础上，完成单个容器职责范围定义。
- 如果使用spring MVC的web模型，一套mvc组件可以划分到一个方框。
- 如果使用DDD领域模型，单个领域模型可以划分到一个方框。
- 标注每个模型的名称，功能模型，关联关系等。
设计要点：
- C3面向的是专业的技术人员，需要使用专业术语清晰技术落地的要点。注：无需关注业务人员是否能看懂。
- 难点在于模型的划分，这个需要不断练习才能涉及更加准确和利的系统，良好的模型涉及反映了设计人员的架构能力。
- compopent将直接指导编程人员，反之最终编程的代码构成也需要和C3模型保持一致。C3的组件应该能找到对应的一个或者多个代码文件。
- 组件的功能之间应该保持独立，组件之间的交互需要需要清洗标注交互协议，强弱关系，交互数据内容，频率范围等。这些信息对于实际的编码和上线后问题排查都会有直接的参考价值。
C4 Code 代码
顾名思义代码级别的设计，用于直接指导具体的代码逻辑。例如：类图，设计模式
设计步骤：
没有固定的步骤，或者说是一门专门的理论。可以参考UML制图的专项学习。
设计要点：
说明代码中类、接口、注解、聚合关系，设计模式、强弱引用，引用方向等等。设计的好坏直接决定的代码的易用性和可扩展性。
这个级别是否要出设计图是存在争议的。Brooks在其著作《人月神话》中直接了当的批评了人工设计UML类图的方法。这种方式需要耗费不少的人力成本，推荐采用代码生成设计的方式，利用自动化生成工具来完成。
补充图谱
C4 模型能够对系统设计进行完整和而清晰的描述，我们在掌握C4架构设计模型的基础上可以通过其他图谱类提供不同的设计视角，来进一步提供设计的其他信息。我们只需要关注图谱的缩放层级即可。
系统鸟瞰图
C1 模型描述了单个系统和其他系统的关系。真实世界中，我们可能需要同时提供多个系统的说明。系统鸟瞰图和C1的基本一致，只是单纯增加更多的系统。只要掌握了C1的画法，多加几个系统即可。
动态图谱
其实就是UML图中的动态行为图，下图和UML中的写作协作图完全一致。只是提供了一种新的参考。用来描述组件和组件之间数据交互流程和协作关系。
部署图
顾名思义主动表述组件的部署架构，包括节点数量，容灾模式，技术选型，数据副本等。这个在UML图中也有，不必特殊对待。
设计工具
首先说明，工具不重要，你可以直接使用一张白纸来完成。
只推荐一个，不是说最好的，而是可以被所有读者考虑的选择。draw.io 免费开源，不受网络限制。