C4 模型 vs UML：你的团队该用哪个？

如果你正在决定团队该如何为软件架构画图，这个选择通常归结到两个名字：UML，那个在 1990 和 2000 年代占据统治地位的正式标准；以及 C4 模型，那个在现代工程团队中已基本取而代之的轻量方法。

对"C4 vs UML"这个问题，诚实的回答比大多数博客文章愿意承认的更微妙。UML 并非毫无用处，C4 也并不完美。它们被设计来解决不同的问题，而正确的选择取决于你的团队究竟需要图来做什么：沟通、规约，还是两者兼有。

本文给你一个平衡的对比——UML 真正做得更好的地方、它在实践中失败的地方、C4 为何成为大多数团队默认的 UML 替代方案，以及一个按团队类型给出的具体结论。

什么是 UML？

统一建模语言（Unified Modeling Language，UML）诞生于 1990 年代中期，当时 Grady Booch、Ivar Jacobson 和 James Rumbaugh 统一了他们相互竞争的面向对象建模表示法。它于 1997 年由对象管理组织（Object Management Group，OMG）标准化，至今仍是一项正式的 ISO 标准。

UML 定义了 14 种图类型，分为两大家族：

  • 结构图：类图、对象图、组件图、组合结构图、部署图、包图和剖面图。
  • 行为图：用例图、活动图、状态机图、时序图、通信图、交互概览图和定时图。

那种广度是 UML 的标志性特征。它几乎能建模任何东西：代码库的静态结构、一笔订单的生命周期、服务之间的消息交换、一次支付的各种状态。理论上，一个完整的 UML 模型就是一个系统的完整规约。

UML 真正的强项

这里值得公允一点，因为 UML 被太轻率地否定了：

  • 它是一个真正的标准。 UML 有正式规约、精确语义，还盖了 ISO 的章。两位都懂 UML 的工程师，会以同样的方式读懂同一张图。没有别的架构表示法能这么说。
  • 行为建模非常出色。 时序图和状态机图依然是"随时间发生了什么"这件事上最广为人知的最佳表示法。C4 的核心层级里没有什么能取代它们。
  • 深厚的工具历史。 数十年的工具——从 Rational Rose 到 Enterprise Architect 再到 PlantUML——都支持 UML，包括代码生成、逆向工程和模型校验。
  • 在某些行业是默认要求。 航空航天、汽车、医疗器械和国防领域常常要求正式模型以用于认证和可追溯性。UML（及其姊妹 SysML）是那里的通用语。

UML 在实践中失败的地方

尽管如此，UML 在主流软件开发中的使用却崩塌了。各种调研和行业经验始终在讲同一个故事：大多数"使用 UML"的团队，实际上只是非正式且不一致地用上了两三种图类型。原因如下：

  • 复杂。 十四种图类型、数百个表示法元素、一份长达 700 多页的规约。掌握 UML 本身就是一个项目，而大多数开发者从未做到。
  • 有形式却无回报。 UML 是为一个"先做大设计（big design up front）"的时代设计的，在那个时代模型驱动代码生成。敏捷开发把这一切颠倒了过来：代码成了真理之源，而重量级的模型成了没人愿意维护的开销。
  • 对架构对话而言抽象层级不对。 UML 最强的地方在类和对象层级——而那恰恰是变化最频繁、在架构讨论中最不重要的层级。它从未定义出一种清晰、共享的方式来回答"这个系统有哪些大的活动部件，它们之间如何通信？"
  • 工程之外没人读的表示法。 把一张 UML 组件图拿给产品经理看，看着他们的眼神逐渐放空。空心箭头 vs 实心箭头、聚合菱形、夹在书名号里的构造型——这套表示法为了精确而牺牲了可读性。

结果是：在今天的大多数公司里，"架构文档"是一堆临时拼凑的方框加箭头、陈旧的 Visio 文件和白板照片的混合体。UML 不是输给了一个更好的标准。它输给了"没有标准"——而这恰恰是 C4 模型填补的空白。

什么是 C4 模型？

C4 模型由 Simon Brown 在 2010 年代创建，采取了相反的路径。它不去定义一套丰富的表示法，而是定义一小组抽象和一个由四个缩放层级构成的层级体系：

  1. 系统上下文（System Context）——你的系统作为一个方框，加上用户和外部系统。
  2. 容器（Containers）——你系统内部的可部署单元（应用、服务、数据库）。
  3. 组件（Components）——每个容器内部的主要构建块。
  4. 代码（Code）——类和函数，通常是生成而非绘制的。

如果你想看每一层的完整走读，请阅读我们的 C4 模型完整指南，或从系统上下文图指南开始。

C4 的强项

  • 抽象优先，表示法其次。 C4 规定每个缩放层级该展示什么，但对你如何绘制刻意保持宽松。方框、箭头和标签就够了。这是团队真正去采用它的最大单一原因。
  • 只有四个层级。 一位开发者一个下午就能学完整个模型。拿它和一门 UML 培训课比一比。
  • 整个团队都能读懂。 一张系统上下文图能给你的 CEO 看。一张容器图能给你的平台团队看。同一个模型通过改变缩放层级、而非改变表示法，服务于每一类受众。
  • 对应系统实际的构建方式。"容器"（可部署单元）和"组件"（模块）比类和对象远更贴合现代云原生开发的心智模型。

值得一提的是，Simon Brown 并没有否定 UML 的思想——他把它们提炼了出来。C4 刻意复用了 UML 的核心洞见，即架构需要多个抽象层级，而它的容器/组件概念也呼应了 UML 的组件图和部署图。区别在于，C4 把一切都为沟通而非正式规约做了优化。

C4 诚实的局限

C4 并不是 UML 所做一切的完整替代品：

  • 它聚焦于结构。 四个核心层级展示存在什么、什么连着什么——而不是随时间发生了什么。对于行为，C4 把你指向补充性的动态图，许多团队干脆把 C4 和 UML 时序图或流程图搭配使用。
  • 它是一种约定，而非正式标准。 没有 ISO 规约，也没有正式语义。对大多数团队来说这是优点；对受监管的行业来说这可能是个问题。
  • 第 4 层基本上是理论性的。 连 Simon Brown 都建议不要手工画代码图——如果你真要用，就从源码生成。

C4 vs UML：并排对比

标准 UML C4 模型
学习曲线 陡峭：14 种图类型、正式表示法、700 多页规约 平缓：4 个层级、方框和箭头、一天就能学会
主要受众 受过训练的工程师和架构师 所有人：高管、PM、架构师、开发者
行为建模 出色（时序图、状态机图、活动图） 有限；依赖补充性的动态/流程图
结构建模 在类级别强，在系统级别缺乏共享约定 从系统上下文到组件，在每个缩放层级都强
标准化 正式的 ISO/OMG 标准，语义精确 非正式约定；广为共享但未标准化
工具 成熟但老化（Enterprise Architect、PlantUML、Visual Paradigm） 不断成长的现代生态（Structurizr、PlantUML C4 扩展、Archyl）
维护负担 高：详细的模型每次重构都会变陈旧 较低：更高的抽象层级变化更少
当今行业采用 小众：受监管行业、学术界、特定图类型 现代软件团队的主流默认选择

你仍然应该用 UML 的时候

选择 C4 并不意味着封杀 UML。有三种情形下，UML 的某些图类型仍是正确的工具。

1. 复杂交互用时序图

当你需要记录"用户结账时跨五个服务究竟发生了什么"时，UML 时序图仍是现有最清晰的表示法。C4 的动态图能覆盖简单情形，但对于带 alt/loop 片段的精巧请求/响应编排，时序图胜出。

2. 生命周期繁重的领域用状态机

订单、订阅、支付意图、文档工作流——任何具有有意义生命周期的东西，都能从一张 UML 状态机图中获益。C4 没有对应物，而发明一个会是个错误。

3. 受监管和安全攸关的环境

如果你的领域要求正式规约、认证产物，或从需求到设计的可追溯性（医疗、航空航天、汽车、国防），那么 UML 或 SysML 可能是合同或法律上的预期。C4 仍可作为其上的沟通层，但它本身满足不了审计员。

大多数团队最终落脚的实用模式是：用 C4 表达结构，用少量补充图表达行为。 把 C4 的四个层级作为你架构文档的主干，然后在行为需要解释时，给特定的容器和组件附上时序图、状态机图或用户流程图。那种组合几乎覆盖了一个典型产品团队的所有文档需求——而无需任何人去学十四种图类型。

结论：你的团队该用哪个？

初创公司和成长期公司：毫不犹豫地选 C4

你需要新人入职第一天就能看懂、并能熬过你下一次转型的图。C4 的系统上下文图和容器图，以 5% 的精力给你 80% 的价值。在单个服务真正变复杂之前，跳过组件图。除非某张特定的时序图物有所值，否则别碰 UML。

大型企业：以 C4 为主干，UML 用在划算的地方

大型组织从 C4 的系统全景（System Landscape）和上下文层级中获益最多——终于有了一张人人都能读懂的投资组合视图。在各团队间用 C4 标准化结构文档，并明确允许对那些值得的工作流使用 UML 时序图和状态机图。如果你身处受监管行业，保留用于认证的正式 UML/SysML 模型，并用 C4 作为面向其他所有人的、对人友好的层。

平台和基础设施团队：以部署为重点的 C4

平台团队生活在容器层级：服务、数据库、队列、网关。C4 容器图加上部署图，直接对应你的世界。UML 类图在这里几乎毫无用处；状态机图偶尔对供给（provisioning）工作流有帮助。

一句话总结

把 C4 作为你默认的架构图标准。当行为有需要时，借用 UML 的时序图和状态机图。把完整的 UML 留给受监管的环境。

Archyl 在实践中如何实现这一点

Archyl 围绕 C4 模型这一一等概念而构建，并直接处理了 C4 在行为方面的空白：

  • 可交互的四层图。 系统、容器、组件和代码元素构成一个可导航的层级体系——点击一个容器即可放大到它的组件，恰如 C4 模型所设想的那样。在我们的 C4 模型页面上探索这一方法。
  • 从代码进行 AI discovery（AI 发现）。 Archyl 不靠手工画图（UML 和手工 C4 努力都死在这一步），而是分析你连接的代码仓库，生成一份 C4 模型草稿——系统、容器、组件和关系——供你审阅和打磨。
  • 用用户流程做行为文档。 经典 C4 把行为留给补充图，而 Archyl 内置了用户流程：把一个用例如何穿行于你的架构逐步可视化，并与所涉及的 C4 元素相链接。这覆盖了团队过去用时序图做的大部分事情。
  • 漂移检测。 每个 UML 模型和每张手绘 C4 图共有的失败模式都是陈旧。Archyl 持续地将你记录在案的模型与实际代码库做比对，并为漂移评分，让文档保持可信。

如果你目前正用 PlantUML 维护架构图、并在评估替代方案，请看我们详细的 Archyl vs PlantUML 对比。

常见问题

我能同时使用 C4 和 UML 吗？

可以，而且对大多数团队来说这是推荐的做法。用 C4 的四个层级做结构文档，然后在运行时行为需要解释的地方附上 UML 时序图或状态机图。C4 自己的动态图明确受到 UML 时序图的启发，所以两者天然地组合在一起。

UML 死了吗？

没有，但它的适用范围已经急剧缩小。作为日常软件团队的一套完整建模方法论，UML 实际上已从主流实践中消失。但作为某些具体而出色的表示法之源——尤其是时序图和状态机图——它依然非常鲜活。它在受监管和安全攸关的行业里也仍是必备。

C4 模型是像 UML 那样的官方标准吗？

不是。C4 是由 Simon Brown 创建、被广泛采用的一种约定，而非 ISO 标准。它有一致的定义和推荐的表示法，但没有正式规约。对大多数团队而言，这份非正式性正是它行得通的原因；而对认证繁重的环境，它可能是个局限。

哪个更适合新开发者入职？

显然是 C4。一位新开发者可以先读一张系统上下文图，再读一张容器图，然后读他将要参与的那个服务的组件图——逐步放大，而无需先学任何表示法。相比之下，UML 类图记录的是一个直接从代码里读更好的细节层级。

准备好不手画一个方框就建起你的 C4 模型了吗？免费试用 Archyl，几分钟内从代码生成你的架构图。或者继续阅读：什么是 C4 模型？完整指南 | C4 系统上下文图指南 | Archyl vs PlantUML。