C4 模型是什么
C4 模型按抽象层级递进描述软件架构，共四层：L1 上下文层看系统与用户、外部系统的关系，L2 容器层看可独立运行的单元（应用、数据库、消息中间件），L3 组件层看容器内部模块与职责，L4 代码层按需展开到类与接口。它的核心主张是“每张图只服务一类读者”，避免用一张图同时满足业务方与开发者的不同关注点。
四个层级
| 层级 | 描述对象 | 主要读者 |
|---|---|---|
| L1 上下文 | 系统与用户、外部系统的关系 | 业务与非技术干系人 |
| L2 容器 | 应用、数据存储、消息中间件 | 技术人员与运维 |
| L3 组件 | 容器内的模块与职责划分 | 开发人员 |
| L4 代码 | 类、接口与实现细节 | 实现者，通常由工具生成 |
基本信息
| 提出者 | Simon Brown 提出的架构可视化方法 |
|---|---|
| 建模单位 | 人、软件系统、容器、组件、代码元素 |
| 配套工具 | Structurizr 用代码描述模型并生成多视图与文档 |
| 常用替代 | PlantUML、Mermaid 手绘近似图，适合轻量场景 |
| 维护策略 | L1 到 L3 手工维护，L4 由工具生成避免过期 |
典型使用场景
- 架构评审：先用 L1 对齐范围，再用 L2 讨论部署与技术选型
- 新人上手：按层级逐层介绍，避免一上来就讲类与接口
- 云迁移评估：在 L2 标出容器与数据存储，逐项判断迁移方式
- 风险沟通：在 L1 标出外部依赖，说明其故障对系统的影响
- 技术方案文档：为每类读者提供对应层级，减少无关细节
- 外包验收：以 L2 与 L3 约定交付边界与模块职责
C4 不规定技术栈也不生成代码，它解决的是沟通问题：同一份模型可以渲染出面向不同读者的多张图，保持术语与命名一致。
直接跳到组件层或代码层画图，业务方无法参与评审，架构中最需要对齐的边界问题反而被跳过。