共计 2508 个字符，预计需要花费 7 分钟才能阅读完成。
一、导读
- 因为向麻利转型，软件架构图的应用规模曾经大幅缩减。即便有在应用软件架构图，它们往往也混淆不清。
- C4 模型由一系列分层的软件架构图组成，这些架构图用于形容上下文、容器、组件和代码。C4 图的层次结构提供了不同的形象级别，每种形象级别都与不同的受众无关。
- 为了避免出现含糊不清的状况，能够在图中蕴含足够数量的文本和要害的图例。
二、C4 概念
软件架构图是一种十分好的表达方式，能够用它们来表白你将如何构建一个软件系统（事后设计）或者现有的软件系统是如何工作的（回顾文档、常识分享和学习）。
然而，你所看到的大多数软件架构图很可能只是由凌乱的框和线组成。麻利软件开发宣言的一个副作用就是让很多团队进行或缩减了他们的图表和文档工作，包含应用 UML。
当初，这些团队偏向于依附他们在白板上绘制的长期图表，或者应用通用的图表工具（如微软的 Visio）。Ionut Balosin 在去年写了一篇叫作“软件架构图的艺术”的文章，他在文章中形容了一些常见问题，这些问题与不可了解的符号和不明确的语义无关。
含糊不清的软件架构图容易导致误会，这可能会拖慢一个优良团队的后退步调。在咱们的行业中，咱们真的应该致力创立出更好的软件架构图。多年来，我本人参加软件开发，并与世界各地的团队单干，基于这些教训，我建设了一个称之为“C4 模型”的货色。C4 代表 上下文（Context）、容器（Container）、组件（Component）和 代码（Code）——一系列分层的图表，能够用这些图表来形容不同缩放级别的软件架构，每种图表都实用于不同的受众。能够将其视为代码的谷歌地图。
要为你的代码创立地图，首先须要一组通用的形象来创立一种无处不在的语言，用来形容软件系统的动态构造。C4 模型应用 容器 （应用程序、数据存储、微服务等）、 组件 和代码 来形容一个软件系统的动态构造。它还思考到应用软件系统的人。
第 1 层：零碎上下文
第 1 层是零碎上下文图，它显示了你正在构建的软件系统，以及零碎与用户及其他软件系统之间的关系。以下是一个零碎上下文图的示例，形容了一个互联网银行零碎的零碎上下文：
银行的集体客户应用互联网银行零碎查看无关银行账户的信息并进行领取。互联网银行零碎应用银行现有的大型机银行零碎来执行此操作，并应用银行现有的电子邮件系统向客户发送电子邮件。图中的色彩示意哪些软件系统曾经存在（灰色）以及待构建的零碎（蓝色）。
第 2 层：容器
第 2 层是一个容器图，将软件系统放大，显示组成该软件系统的容器（应用程序、数据存储、微服务等）。技术决策也是该图的要害局部。以下是互联网银行零碎的容器图示例。它显示了互联网银行零碎（虚线框）由五个容器组成：服务器端 Web 应用程序、客户端单页面应用程序、挪动应用程序、服务器端 API 应用程序和数据库。
Web 应用程序是一个 Java/Spring MVC Web 应用程序，它仅提供动态内容（HTML、CSS 和 JavaScript），包含组成单页应用程序的内容。单页面应用程序是一个运行在客户网络浏览器中的 Angular 应用程序，提供所有的网上银行性能。或者，客户能够应用跨平台 Xamarin 挪动应用程序拜访互联网银行的局部性能。单页应用程序和挪动应用程序都调用 JSON/HTTPS API，这是由服务器端运行的另一个 Java/Spring MVC 应用程序提供的。API 应用程序从数据库中获取用户信息（关系数据库模式）。API 应用程序还应用专有的 XML/HTTPS 接口与现有的大型机银行零碎进行通信，以获取无关银行账户或交易的信息。如果须要向客户发送电子邮件，API 应用程序还会调用现有的电子邮件系统。
第 3 层：组件
第 3 层是组件图，将单个容器放大，以显示其中的组件。这些组件映射到代码库中的实在形象（例如一组代码）。上面是一个虚构的网上银行零碎的组件图示例，显示了 API 应用程序中的一些组件（而不是全副）。
两个 Spring MVC REST 控制器为 JSON/HTTPS API 提供拜访点，每个控制器随后应用其余组件拜访数据库和大型机银行零碎中的数据。
第 4 层：代码
最初，如果你的确想要，或者说有这个必要，能够放大个别组件，以显示该组件的实现形式。以下是一个虚构的网上银行零碎的 UML 类图示例（局部），显示了组成 MainframeBankingSystemFacade 组件的代码元素（接口和类）。
它表明该组件由很多类组成，实现细节间接反映了代码。我并不倡议创立在这种具体水平的图表，有时候你能够间接从大多数 IDE 中获取它们。
符号
C4 模型没有预约义任何特定的符号，你在这些示例图中看到的是一个个简略的符号，实用于白板、纸张、便签、索引卡片和各种图表工具。你也能够应用 UML 作为符号，并适当应用包、组件和原型。无论你应用哪种符号，我都会倡议让每个元素都蕴含名称、元素类型（即“人”、“软件系统”，“容器”或“组件”）、技术选型（如果有的话），以及一些描述性文字。在图表中蕴含如此多的文本可能看起来很不寻常，但这些附加文本有助于打消软件架构图中通常会呈现的不明确的示意。
即便符号对你来说是不言而喻的，依然要确保为这些符号提供图例。图例中应该包含色彩、形态、首字母缩略词、线条款式、边框、尺寸等。现实状况下，符号应该在每个细节档次上保持一致。上面是后面显示的容器图的图例。
最初，不要遗记了题目，它应该呈现在每个图表上，以明确地形容每个图表的类型和范畴（例如，“网上银行零碎的零碎上下文图表”）。
更多信息
C4 模型是一种在不同抽象层次上交换软件架构的简略办法，能够向不同的受众讲述不同的故事。这也是向软件开发团队介绍（通常是从新引入）谨严和轻量级建模的一种形式。无关 C4 模型的更多信息，以及补充图（运行时和部署）的示例、符号清单、常见问题解答、会议讲座视频和工具选项，请参阅 c4model.com。
查看英文原文：The C4 Model for Software Architecture
相干文章：
用于软件架构的 C4 模型
DDD 作者 Eric Evans 欲改良 DDD 设计语言
在线画图软件 structurizr.com
学习总结——架构办法、软件建模与设计文档
DDD：C4 model 畛域驱动设计系列
