架构制图：工具与方法论( 八 )

软件系统（Software System）：作为最高层次抽象，描述了给用户创造价值的软件制品；既包括当前正在设计的软件系统，也包括该系统所依赖（或被依赖）的其他软件系统。一个软件系统通常是由单个软件开发团队所负责。

在绘制系统上下文图时，不需要关心诸如技术栈、协议等任何底层细节。这类图的受众是最广的，因为任何人都可以理解并从中获取到足够的信息，包括技术人员和非技术人员，也包括团队内成员和团队外成员。
3）Level 2：Container diagram

本文插图
通过 L1 的上下文图理解了系统在整个 IT 环境中的定位后，下一步就是把系统这个框框放大，详细看下其中包含了哪些“容器”（Container ，注意不要跟 Docker 容器搞混了噢！）。 C4 模型中的容器是指单个应用或数据存储，通常可以独立部署和运行（有独立的进程空间，通过 IPC 机制互相通讯），例如：SpringBoot 微服务、React SPA、移动 App、数据库、Serverlss 函数、Shell 脚本。
L2 的容器图不仅展示了系统的进一步职责拆分，还包括了主要的技术选型、容器之间的通讯方式等关键架构信息。这类图可以面向全部的技术人员，既包括架构师、开发者，也包括运维人员、技术支持等。
4）Level 3：Component diagram

本文插图
继续前面的套路，下一步就是把系统中各个容器再分别进行局部放大，将每个容器进一步拆分成多个组件（Component）。在 C4 模型中，组件是指一组通过良好接口定义封装在一起的相关功能（通常运行在同一个进程空间内），例如：Spring 里的一个Controller（不只包括定义了 REST 接口的 Controller 主类，也包括背后所有相关联的实现类，如 Service/Repository 等）。
与容器图类似， L3 的组件图也不只包含了容器的组件划分，还包括各个组件的职责定义、技术与实现细节等。随着层次的下沉和细节的增多，组件图的受众范围进一步缩窄，一般只适用于软件架构师和开发者（其他角色没必要理解，一般也理解不了）。
5）Level 4：Code（可选）

本文插图
再继续对组件进行放大，所能看到的最底层和细节的信息，就是 L4 的代码（Code）了。当然，这里所谓的“代码”还是以图的形式（e.g. UML 类图、数据库 E/R 图）展示类或文件粒度的代码结构，并不是真正的代码本身。即便如此，代码图在 99% 的架构描述场景下也依然过于详尽，一方面数量庞大，绘制成本很高；另一方面易于变化，维护成本也非常高。因此，一般只有非常重要和复杂的组件才需要用到这一层级进行描述。如果确实需要绘制，也应该优先考虑自动化的方式，比如很多 IDE 就支持自动生成 UML 类图。
6）补充图：Landscape / Dynamic / Deployment Diagram