引言：我们画的架构图，别人真的能看懂吗？

如果你请一位建筑师描述一栋建筑的结构，他会拿出平面图、立面图、剖面图——每一张图都有明确的用途、标准的符号、清晰的受众。但如果你请一位软件工程师画出系统的架构，你大概率会得到一堆含义不明的方框和线条。

这不是个别现象。Simon Brown（C4 Model 的作者）在多年的咨询和培训中观察到，软件行业的架构图普遍存在以下问题：

• 符号没有图例说明，颜色和形状的含义全靠猜
• 元素的职责模糊，充斥着"业务逻辑"这类万能标签
• 关系线没有标注方向和含义，甚至缺失
• 不同层次的抽象混在一张图里，既有数据库表又有整个系统
• 多张图之间的符号、命名、阅读顺序互不一致

行业里并非没有建模语言——UML、ArchiMate、SysML 都是成熟的体系。但现实是，大量团队已经抛弃了这些语言，转向了更简单的"框图"画法。问题在于，抛弃复杂建模语言的同时，团队也丢掉了用图形有效沟通架构的能力。

C4 Model 就是在这个背景下诞生的。它不是另一套复杂的建模语言，而是一种帮助团队重新建立架构沟通能力的方法——用最简单的方式，画出别人真正能看懂的架构图。

核心隐喻：代码的地图

C4 Model 的核心思想可以用一个类比概括：像使用地图一样描述你的代码。

想想你在 Google Maps 上查看一个地点的方式。最高层级你看到的是整个城市的轮廓和它与周边城市的关系；放大一级，你看到城区内的主要道路和区域划分；再放大，你看到具体的街道和建筑；最终你可以放大到一栋建筑的门牌号。每一层都有不同的细节量，服务于不同的目的。你不会在城市总览图上标注每一栋建筑，也不会在街道图上显示整个国家的轮廓。

C4 Model 对软件架构做了同样的事情。它定义了四个从粗到细的抽象层次，每一层都是对上一层某个元素的"放大"——逐层深入细节，每一层回答不同的问题，面向不同的受众。

四层抽象

C4 中的"C4"就是这四个层次的首字母：Context、Containers、Components、Code。

第一层：System Context（系统上下文）

回答的问题： 这个系统是什么？谁在用它？它和外部世界如何交互？

这是最高层级的视图。图中的核心是你正在构建的软件系统，围绕它的是使用者（人）和它依赖或被依赖的外部系统。这张图故意隐藏了所有内部技术细节——它面向的受众包括非技术人员，目的是让所有人对系统的边界和外部关系建立共识。

第二层：Container（容器）

回答的问题： 这个系统内部由哪些主要的可运行/可部署单元组成？它们之间如何通信？

这里的"Container"不是 Docker 容器。在 C4 的术语中，Container 指的是独立运行的应用程序或数据存储——例如一个 Web 应用、一个 REST API 服务、一个数据库、一个消息队列、一个文件系统。Container 图展示的是系统内部的高层技术架构：有哪些运行单元，各自的技术选型是什么，彼此之间用什么协议通信。

这是 C4 Model 中最重要的一层，也是 Simon Brown 最推荐团队优先绘制的图。它的受众是有技术背景的人——开发者、架构师、运维人员。

第三层：Component（组件）

回答的问题： 一个 Container 内部由哪些主要的功能模块组成？

Component 图将一个 Container 的内部打开，展示其中的关键组件以及它们之间的关系。这里的"组件"通常对应代码中的一组相关类或模块——比如一个 Controller 层、一个 Service 层、一个 Repository 层，或者按业务领域划分的模块。

这张图的受众主要是直接参与该 Container 开发的工程师。Simon Brown 建议，不是所有 Container 都需要画 Component 图——只在有沟通价值时才画。

第四层：Code（代码）

回答的问题： 一个 Component 内部的代码结构是什么？

这一层通常就是传统的 UML 类图或实体关系图。C4 Model 的建议是：在绝大多数情况下，你不需要手动画这一层——现代 IDE 和工具可以自动生成，而且代码本身就是最精确的文档。

值得注意的是，C4 官方明确指出：不需要使用全部四层，只用对团队有价值的层级即可。 对大多数团队来说，System Context 和 Container 两层就已经足够了。

Notation：不绑定符号，但约束信息完整性

C4 Model 的一个重要设计决策是符号无关（notation independent）。它不强制你使用特定的形状、颜色或线型——你可以用方框、圆角矩形、甚至手绘草图，都没有问题。这与 UML 形成了鲜明对比：UML 定义了一整套严格的图形符号体系（棒人代表 Actor、圆柱体代表数据库等），学习和使用的门槛都很高。

但"符号无关"不意味着"随便画"。C4 对图的信息完整性有一组明确的约束：

对图本身： 每张图必须有标题（说明图的类型和范围），必须有图例（Key/Legend）解释所有用到的符号约定——形状、颜色、线型各代表什么。即使你使用 UML 或 ArchiMate 的符号来画 C4 图，也应该加上图例，因为不是每个读者都熟悉这些符号体系。

对元素： 每个元素必须标注类型（Person、Software System、Container 或 Component），必须有简短的职责描述，Container 和 Component 还必须标注技术选型。

对关系： 每条连接线必须是单向的，必须标注关系的含义（而且要具体，不能只写一个"Uses"），容器之间的通信还必须标注技术协议。

这套约束的设计哲学很清晰：C4 不关心你用什么形状画图，它关心的是你有没有把关键信息写上去。一张没有图例、没有元素描述、箭头不标注含义的架构图，无论形状画得多漂亮，都是失败的沟通。C4 的 notation 规范本质上是一个信息完整性的检查清单，而不是一本符号字典。

补充图类型

除了核心四层的静态结构图，C4 还提供了几种补充图类型以覆盖更多的架构沟通场景：

Dynamic Diagram（动态图）： 用于描述元素之间在运行时的交互顺序，类似 UML 的序列图，但使用 C4 的元素和 notation 原则。它可以在任意一个 C4 层级上绘制——你可以画系统间的交互时序，也可以画组件间的调用流程。

Deployment Diagram（部署图）： 用于描述 Container 在不同环境（生产、预发、开发）中的实际部署拓扑——部署在哪些节点上、如何组织。

这两种图是对核心四层的实用补充，分别覆盖了运行时行为和物理部署这两个维度。

层次的扩展性：四层之上与四层之间

System Landscape：往上看全局

C4 的核心四层聚焦于单个软件系统的描述。但在真实的企业环境中，系统不会孤立存在。当你需要展示一个组织或部门内所有系统的全景时，C4 提供了 System Landscape 图。它本质上就是一张不聚焦于特定系统的 System Context 图——把视角从"一个系统与它的外部关系"拉远到"所有系统之间的关系"。对于大型组织来说，Landscape 图是连接 C4 与企业架构视角的桥梁。

更多层次：允许但谨慎

一个自然的问题是：四层够用吗？如果系统足够复杂，能否在 Container 和 Component 之间再插入一层？

Simon Brown 对此的态度是明确的：可以，但这是一个高级操作（advanced manoeuvre），需要谨慎对待。

他观察到，大多数团队想要增加层次的原因其实是以下两种情况之一：

第一，对现有层次的定义理解有误，导致误用。例如把"数据库"这个词不加区分地使用——它可能指一个数据库服务器（Container），也可能指一个 schema（也是 Container），也可能指一组相关的数据表（Component 级别）。很多"四层不够用"的困惑，根源在于术语的不精确。

第二，想把组织概念（子系统、限界上下文、分层、库）映射为 C4 的抽象层，但这些概念本身并不是独立的抽象层级，更多是逻辑分组或设计模式。

C4 Model 的核心力量恰恰在于它的小而固定的层次体系——正是因为只有四层，团队才被迫精确思考每个元素属于哪一层，这个过程本身就在推动术语的统一和架构认知的对齐。如果随意增加层次，这个约束力就会被稀释，最终退化为又一套含义模糊的框图。

所以 Simon Brown 的建议是：如果你确实需要增加层次，你必须投入精力去精确定义新层次的含义——它代表什么抽象、与相邻层的边界在哪里、判定标准是什么。如果做不到这一点，就不应该加。

总结

C4 Model 的核心贡献不在于发明了新的图形符号，而在于为软件架构的可视化沟通提供了一个简单、分层、可落地的框架：

• 四层逐级放大机制让不同受众在不同粒度上理解同一个系统
• Notation 原则不限制表达形式，但要求信息完整
• 层次体系简单但有约束力，迫使团队精确使用术语

C4 不试图替代 UML 或 ArchiMate，也不试图覆盖架构的所有维度。它的定位很明确：帮助团队画出别人能看懂的架构图。

本文的内容提炼自 C4 Model 官方网站（c4model.com）上 Simon Brown 的原始阐述，经过笔者的理解和重新组织。理解难免有偏差之处，强烈建议感兴趣的读者访问 c4model.com 阅读原文。如果你有不同的理解或看法，欢迎在评论区留言交流。

在本系列的下一篇文章中，我们将跳出 C4 Model 的官方定义，分享一些基于实践的延伸思考：C4 的四层抽象与经典 4+1 视图模型之间是什么关系？当我们沿着层次逐级放大时，除了元素本身被细化，图中的其他信息——关系、行为、部署——是否也应该随之展开？在大规模系统中，如果四层不够用，中间层该如何定义？这些问题没有标准答案，但值得每一个使用 C4 的团队认真思考。