对于软件开发团队来说，写软件设计文档，花架构图，是日常工作中的关键一项。

而其中，如何画好系统设计的架构图呢？ Simon Brown 就 提出 C4 模型，来解决这个问题。

基于C4模型的脚手架，架构师们就可以统一团队内的不同层级的视角，交付一个成体系的架构设计。

下面具体看一下C4模型吧。

什么是C4模型？

C4 模型是一种轻量级的软件架构图的表示法，旨在帮助团队更好地理解和沟通软件架构设计。

C4代表了四个层次的抽象化，即：

  • 上下文（Context）：上下文层次主要描述了软件系统与外部系统或人员之间的交互关系，其目的是为了提供软件系统的背景和整体结构。
  • 容器（Container）：容器层次描述了软件系统中的容器（如服务器、数据库等）以及它们之间的关系，其目的是为了提供软件系统内部的大体结构。
  • 组件（Component）：组件层次描述了容器内的组件（如Web应用程序、服务、数据库架构等）以及它们之间的关系，其目的是为了更细致地了解软件系统的内部组成。
  • 代码（Code）：代码层次描述了组件内的代码实现，其目的是为了帮助开发者更好地了解组件的实现和技术细节。

如上图所示，这四个层次对应着从高到低的不同的抽象程度。对应到软件系统中来说，就是能够从不同的层级视图上，展示软件的架构，使得设计者和开发者们可以更好地理解、交流架构设计，并推进架构的演进升级。

第1级:系统上下文图

系统上下文图是软件系统设计的起点，是让你后退一步以看到大的视角。

画一个图表，将你的系统显示为中心的一个盒子，周围是展现的主要是两类信息：

  • 本系统的用户是谁；
  • 本系统如那些外部系统有交互。

细节在这里并不重要，因为这是你缩小的视图，显示了系统全景的大图。重点应该放在人(参与者、角色、角色等)和软件系统上，而不是技术、协议和其他低级细节上。这是一种可以展示给非技术人员的图表。

  • 呈现范围：单个软件系统。
  • 主要元素：范围内的软件系统。
  • 支持元素：在范围内直接连接到软件系统的人员(例如用户、参与者、角色或角色)和软件系统(外部依赖项)。通常，这些其他软件系统位于您自己的软件系统的范围或边界之外，您对它们没有责任或所有权。
  • 目标受众：每个人，包括技术人员和非技术人员，软件开发团队内外的人员。
  • 注意：推荐推荐给大多数团队。

第2级：容器图

此处的容器，不是指Docker的一个容器。

而是类似于服务器端web应用程序、单页应用程序、桌面应用程序、移动应用程序、数据库模式、文件系统等。

本质上，容器是一个单独的可运行/可部署单元(例如，一个单独的进程空间)，用于执行代码或存储数据。

系统上下文图将本系统看作一个黑盒，那么容器图则是把这个黑盒打开，深入到了软件的内部，展示了软件内体系结构的高级形状，以及职责如何在其中分布。

它还展示了主要的技术选择以及容器之间如何通信。

这是一个简单的、以技术为重点的高级图表，对软件开发人员和支持/操作人员都很有用。

  • 呈现范围：单个软件系统。
  • 主要元素：范围内软件系统中的容器。
  • 支持元素：直接连接到容器的人员和软件系统。
  • 目标受众：软件开发团队内外的技术人员;包括软件架构师、开发人员和操作/支持人员。
  • 注意：推荐推荐给大多数团队，该图没有说明部署场景、集群、复制、故障转移等。

第3级：组件图

组件图，则是进一步放大并分解了每一个容器，

接下来，您可以放大并进一步分解每个容器，以识别容器内的主要结构构建块，及其互相之间的交互关系。

组件图展示了容器是如何由许多“组件”组成的，每个组件是什么，它们的职责和技术/实现细节等。

  • 呈现范围：单个容器。
  • 主要元素：范围内容器中的组件。
  • 支持元素：容器(在软件系统范围内)加上直接连接到组件的人员和软件系统。
  • 目标受众：软件架构师和开发人员。
  • 注意：不推荐给大多数团队，如果你觉得组件图增加了价值，那么只创建组件图，并考虑为长期存在的文档自动化创建组件图。

第4级：代码结构图

如果需要深入到组件代码层面，代码结构图可以显示组件是如何作为代码来实现的。主要是使用使用UML类图、实体关系图或类似的方法。

理想情况下，这种底层细节的图表，将使用工具(例如IDE或UML建模工具)自动生成，应该考虑只显示那些，你想要重点关注的属性和方法。

所以，除了最重要或最复杂的组件之外，不建议使用这种详细级别。

  • 呈现范围：单个组件。
  • 主要元素：组件作用域中的代码元素(例如类、接口、对象、函数、数据库表等)。
  • 目标受众：软件架构师和开发人员。
  • 注意：不推荐用于大多数团队，对于长期存在的文档，大多数IDE工具都可以按需生成这种级别的详细信息。

使用C4模型的6个注意点

在团队架构中，使用C4模型来呈现架构视图时，需要注意以下几点：

  • 目标清晰：在绘制C4模型之前，应该明确需要建模的系统、软件或架构的目标。确保每个层次上的图表都有明确的目的，能够传达给观众或其他利益相关者有关系统或软件的信息。

  • 约定标识符：在绘制C4模型时，应使用一致的标识符来命名和标识不同的元素，例如系统、容器、组件和代码等。这有助于提高模型的可读性和理解性。

  • 简单明了：C4模型强调简洁、清晰的表述。在绘制C4模型时，应避免使用过多的细节或技术语言，以确保每个层次上的图表都易于理解。

  • 易于更新：C4模型应该能够随着时间的推移而更新，以反映系统或软件架构的演变。在绘制C4模型时，应该考虑如何使其易于维护和更新。

  • 适度细节：在绘制C4模型时，应考虑到每个层次上需要展示多少细节。如果图表过于复杂，可能会导致人们难以理解和使用。

  • 迭代性：C4模型是一个迭代的过程。在实践中，您可能需要多次绘制和修改C4模型以满足需求，并使其更好地反映系统或软件架构。

总之，C4模型是一种简单但强大的建模方法，可以帮助您建立清晰、易于理解和易于维护的软件架构图表。通过遵循上述建议，您可以更好地使用C4模型来设计和描述复杂的软件系统。

实践中常见的6个误区

在使用C4模型时，可能会遇到一些常见的误区。

以下是一些常见的误区，以及如何避免这些问题的方法：

  • 过度关注细节：C4模型旨在提供一个高层次的概述，以帮助人们理解系统或软件架构。因此，过度关注细节可能会使模型过于复杂，难以理解。建议在模型的每个层次上保持适度的细节，以便读者可以轻松理解。

  • 忽略系统间的交互：C4模型强调系统的上下文视图，但有时候人们可能会忽略系统之间的交互。在建模时，应该考虑系统之间的交互以及它们如何在软件架构中发挥作用。

  • 忽略时间和演变：C4模型应该是可演化的，这意味着模型应该能够反映软件架构的演变。在建模时，应该考虑如何使模型易于更新和维护，以便反映软件架构的演变。

  • 与UML混淆：虽然C4模型和UML有些相似之处，但它们是不同的建模方法。C4模型的重点是软件架构，而UML的重点是面向对象的编程。因此，建议不要将C4模型与UML混淆。

  • 未充分考虑受众：C4模型的目的是使软件架构易于理解。因此，在绘制模型时，应该考虑模型的受众群体，并为他们提供足够的上下文信息和详细说明。

  • 忽略安全和性能：在建模软件架构时，应该考虑安全和性能方面的因素。这些因素对系统的设计和实现都有重要影响，因此应该在C4模型中考虑它们。

总之，避免这些常见的误区，可以在你的软件架构建模工作中，让C4模型更好的发挥作用。

写在最后

C4模型的架构设计的脚手架，值得推荐的关键：就是其为架构设计图，提供了一个分层的清晰的结构规范。

一份可视化的 C4 模型 架构视图，可以让团队内的人，从不同层面上入手，快速到找到自己关注的要点，这是非常有利于团队内对系统设计的沟通的。