C4 架构模型

C4 架构模型（也称为 C4 模型）是由软件架构师 Simon Brown 提出的一种用于可视化软件架构的简单分层方法。它的核心目标是解决架构文档化中的常见问题：过于抽象、缺乏细节、晦涩难懂或过于冗长复杂。

C4 模型的名字来源于其定义的四个核心抽象层次（都以字母 “C” 开头）：

1. Context (上下文)
2. Containers (容器)
3. Components (组件)
4. Code (代码)

这四层提供了从宏观系统概览到微观代码实现的不同粒度的视图，允许你根据受众（如业务干系人、架构师、开发人员）和目的（如整体规划、系统设计、模块设计）选择合适的抽象级别进行描述。

---

C4 模型的核心层次详解

1. 第1层：系统上下文图 (System Context Diagram)

   • 目标： 定义系统的边界，展示该系统与外部用户和其他系统（人或软件系统）的交互关系。
   • 内容：
     • 待描述的核心软件系统（用一个方框表示）。
     • 与该系统交互的人角色（如客户、管理员）。
     • 与该系统交互的外部系统（如支付网关、邮件服务、数据库、第三方API）。
     • 核心系统与这些外部实体之间的关键数据流或交互关系（用连线表示）。
   • 受众： 所有人（包括非技术人员、业务人员、管理层、新团队成员）。这是最高层次的概览。
   • 重点： “谁”在使用这个系统，“什么”外部系统与之交互。

2. 第2层：容器图 (Container Diagram)

   • 目标： 放大核心系统，展示其内部的高层次技术结构。一个“容器”代表一个可独立运行/部署的应用程序或数据存储单元。
   • 内容：
     • 容器： Web应用（如Spring Boot应用）、移动应用（如iOS App）、单页应用（如React SPA）、微服务、数据库（如MySQL）、消息队列（如Kafka）、文件存储、Serverless函数等。每个容器都是一个独立的进程或执行环境。
     • 容器之间的交互关系（API调用、消息传递、数据库访问）。
     • 容器与外部系统/用户（来自Context层）的交互。
     • 技术选择（可选，但推荐注明关键技术，如“Node.js API”、“PostgreSQL DB”）。
   • 受众： 技术相关人员（架构师、开发人员、运维人员）。
   • 重点： 系统由“哪些主要技术模块（容器）”组成，它们“如何”交互协作。这层揭示了系统的整体形态（单体？微服务？）。

3. 第3层：组件图 (Component Diagram)

   • 目标： 放大某个特定容器，展示其内部的主要逻辑组件及其关系。组件是容器内一组相关功能的封装。
   • 内容：
     • 组件： 代表容器内部的主要功能模块（如“订单服务”、“用户认证”、“库存管理”、“支付处理”、“报告生成”）。组件通常映射到代码库中的模块、包、命名空间或一组强相关的类。
     • 组件之间的交互关系（方法调用、事件触发）。
     • 组件与容器边界外的其他容器或外部系统的交互（可以简化表示）。
     • 职责：清晰描述每个组件的核心职责。
   • 受众： 负责设计和实现该容器的开发人员、架构师。
   • 重点： 某个容器内部“有哪些关键功能模块（组件）”，它们“如何”分工协作完成该容器的功能。

4. 第4层：代码图 (Code Diagram)

   • 目标： 放大某个特定组件，展示其内部具体的类、接口、对象及其关系。这是最接近实际代码的视图。
   • 内容：
     • 类、接口、枚举等代码元素。
     • 它们之间的关系（继承、实现、关联、依赖等）。
     • 通常使用 UML 类图或实体关系图来表示。
   • 受众： 负责实现和维护该组件的开发人员。
   • 重点： 组件内部“具体如何”通过代码结构和类来实现功能。注意： 这层图通常可以由 IDE 或建模工具从代码中（半）自动生成，不一定需要手工维护。

---

C4 模型的关键原则与优势

1. 分层抽象： 核心优势，避免信息过载，让不同角色关注不同层次。
2. 基于场景： 每张图都应该服务于一个特定的目的或回答一组特定的问题。
3. 图即文档： 图本身是文档的核心部分，辅以必要的文字说明（如每个元素的职责描述）。
4. 清晰标注： 每个元素（系统、容器、组件、外部实体）都应该有明确的名称和清晰的职责描述。
5. 技术栈可选： 在 Context 层通常不涉及技术细节，在 Container 层建议注明关键技术，在 Component 和 Code 层技术细节自然显现。
6. 以人为本： 强调图的可读性和沟通效率，避免使用只有专家才能看懂的复杂符号。
7. 灵活性与实用性： 不是强制标准，可根据项目规模和复杂度裁剪使用（例如，小型项目可能不需要 Component 图）。它很好地补充了 UML 等更形式化的方法。

---

如何使用 C4 模型

1. 选择合适的工具：
   • 绘图工具：draw.io (推荐，内置C4模板), Microsoft Visio, Lucidchart, PlantUML (支持C4宏库), Mermaid (支持C4语法), Structurizr (Simon Brown 提供的在线工具和 DSL)。
   • 文档工具：Markdown (配合图文件或在线图链接), Confluence, Wiki。
2. 从 Context 开始： 始终从最宏观的上下文图入手，明确系统边界。
3. 逐层深入： 根据需要对关键系统绘制 Container 图，再对关键容器绘制 Component 图。Code 图通常按需生成。
4. 保持更新： 随着系统演进，同步更新相关的架构图。将图作为代码库的一部分管理有助于同步。
5. 作为沟通基础： 在讨论系统设计、新功能设计、入职培训、故障排查时，使用对应的 C4 图作为讨论的起点和共同语言。

---

总结

C4 模型是一个强大而实用的软件架构可视化框架。它通过四个递进的抽象层次（Context -> Containers -> Components -> Code），为不同受众提供了清晰、简洁且具有针对性的架构视图。它极大地改善了团队内部以及与外部干系人之间的技术沟通效率，促进了更好的架构设计理解和文档化。无论是构建新系统还是理解遗留系统，C4 模型都是一个值得掌握的必备工具。

层级	名称	核心关注点	关键元素	典型受众	类比（建筑）
1. Context	系统上下文图	系统边界：系统是什么？谁/什么在使用它？它和哪些外部系统交互？	核心系统、人角色、外部系统、交互关系	所有人（业务/技术/管理）	城市地图：建筑在城市的哪里
2. Container	容器图	高层次技术结构：系统内部由哪些主要技术模块组成？它们如何交互协作？	容器（Web App, API, DB, MQ…）、交互关系	技术相关人员（架构/开发/运维）	建筑蓝图：楼层/房间布局
3. Component	组件图	容器内部结构：某个容器内部有哪些主要功能模块？它们如何分工协作？	组件（功能模块）、交互关系、职责	负责该容器的开发者/架构师	房间设计图：家具电器布置
4. Code	代码图 (可选细节)	组件实现细节：某个组件内部具体由哪些类和对象组成？它们的关系如何？	类、接口、对象、关系（UML类图风格）	实现该组件的开发者	家具构造图：螺丝螺母如何装