软件架构C4模型入门
我仍然记得那次让我重新思考架构图一切的白板会议。我们正在为一位新开发者做入职培训，我花了45分钟画方框和箭头试图解释我们的电商平台。到最后，她看起来比开始时更困惑。图表包含了所有内容——微服务、数据库、消息队列、外部API——全部挤在一起，符号不一致，没有清晰的层级。
那天晚上，我偶然发现了Simon Brown的C4模型，这是一个"为什么我没想到"的时刻。这个想法看似简单：不是把所有东西塞进一张图，而是在不同缩放级别创建多张图。就像Google地图，你从全局视图开始，然后逐步放大查看更多细节。
C4的四个层级
"C4"代表四个抽象层级，每个层级回答不同的问题：
第1层：系统上下文
这是30,000英尺的视角。你的整个系统是一个方框，你展示：
- 谁使用你的系统（人员或角色）
- 你集成了哪些外部系统
仅此而已。没有内部细节，没有技术选择，没有数据库。当我第一次为我们的平台画系统上下文图时，它可以放在一张幻灯片上。我们的CEO能看懂。这在我之前的架构图中从未发生过。
第2层：容器图
现在我们放大一层。C4术语中的"容器"不是Docker容器——它是运行代码或存储数据的任何可部署单元：Web应用、移动应用、后端服务、数据库、消息队列、文件存储。
第3层：组件图
这是我们缩放到单个容器内部的地方。组件是该容器内的主要结构构建块——想想服务、仓储、控制器或模块。
第4层：代码图
最深层级展示实际的代码元素——类、接口、函数。Simon Brown自己说这个层级是可选的，通常从代码自动生成。
为什么C4对我们团队管用
在C4之前，我们的架构文档一团糟。C4模型给了我们一个真正有效的框架：
简单到能记住
四个层级。就这些。不需要记住14种不同的UML图类型。
不同受众，不同图表
CEO看系统上下文图。架构师讨论容器图。开发者使用组件图。每个人获得适合他们需求的详细级别。
保持更新
因为C4图相对简单，更新它们不会痛苦。
工具无关
C4模型适用于任何工具，因为它关注的是概念，而不是符号。
我犯过的常见错误
错误1：过早展示太多细节
我的第一张容器图有47个方框。准确但没用。
错误2：忘记关系
只有方框没有箭头的图表只是一个清单。关系往往比方框本身更重要。
错误3：变更后不更新
最好的图表如果描述的是两年前的系统也是没用的。
错误4：过度设计符号
专注于内容，而不是美学。
开始使用
- 从系统上下文开始。花30分钟画出你的系统。
- 添加一张容器图。选择最复杂的系统并拆解。
- 先到这里。让图表证明其价值后再投入更多时间。
- 让它协作化。与团队分享图表。
总结
C4模型在概念上并非革命性的。Simon Brown出色地将这些想法包装成一个简单、易记的框架，而且真的会被使用。
如果你的架构文档是过时的Visio文件和白板照片的混乱集合，试试C4吧。从小处开始，只画一张系统上下文图。你可能会惊讶于一张经过深思熟虑的图表能带来多大的清晰度。
这是我们架构文档系列的一部分。接下来：AI如何自动发现你的架构和为什么文档比你想象的更重要。