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

而其中,如何画好系统设计的架构图呢? 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 模型 架构视图,可以让团队内的人,从不同层面上入手,快速到找到自己关注的要点,这是非常有利于团队内对系统设计的沟通的。