用于可视化软件架构的 C4 模型

不同级别的缩放允许您向不同的受众讲述不同的故事。

系统上下文图是绘制和记录软件系统的良好起点，让您可以退一步查看全局。 绘制一个图表，将您的系统显示为中心的一个盒子，周围是它的用户和与其交互的其他系统。

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

范围 ：单个软件系统。

主要要素 ：范围内的软件系统。
支持元素 ：在范围内直接连接到软件系统的人员（例如用户、参与者、角色或角色）和软件系统（外部依赖项）。 通常，这些其他软件系统位于您自己的软件系统的范围或边界之外，并且您对它们没有责任或所有权。

目标受众 ：软件开发团队内部和外部的每个人，无论是技术人员还是非技术人员。

推荐给大多数团队 ：是的。

一旦您了解了您的系统如何适应整个 IT 环境，下一步真正有用的就是使用容器图放大系统边界。 “容器”类似于服务器端 Web 应用程序、单页应用程序、桌面应用程序、移动应用程序、数据库模式、文件系统等。本质上，容器是一个单独的可运行/可部署的单元（例如单独的进程空间） ）执行代码或存储数据。

容器图显示了软件架构的高级形状以及如何在其中分配职责。 它还显示了主要的技术选择以及容器如何相互通信。 这是一个简单的、以高级技术为中心的图表，对于软件开发人员和支持/操作人员等非常有用。

范围 ：单个软件系统。

主要元素 ：软件系统范围内的容器。
支持元素 ：直接连接到容器的人员和软件系统。

目标受众 ：软件开发团队内外的技术人员； 包括软件架构师、开发人员和运营/支持人员。

推荐给大多数团队 ：是的。

注意 ：该图没有提及集群、负载均衡器、复制、故障转移等，因为它可能会因不同环境（例如生产、登台、开发等）而有所不同。 通过一个或多个部署图 可以更好地捕获这一信息 。

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

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

范围 ：单个容器。

主要元素 ：范围内容器内的组件。
支持元素 ：容器（在软件系统范围内）加上直接连接到组件的人员和软件系统。

目标受众 ：软件架构师和开发人员。

建议大多数团队 ：不，仅在您认为组件图增加价值时才创建组件图，并考虑自动创建长期文档。

最后，您可以放大每个组件以显示它是如何实现为代码的； 使用 UML 类图、实体关系图或类似的图。

这是一个可选的详细级别，通常可以通过 IDE 等工具按需获取。 理想情况下，该图将使用工具（例如 IDE 或 UML 建模工具）自动生成，并且您应该考虑仅显示那些允许您讲述您想要讲述的故事的属性和方法。 除了最重要或最复杂的组件之外，不建议对任何其他组件使用这种详细程度。

范围 ：单个组件。

主要元素 ：范围内组件内的代码元素（例如类、接口、对象、函数、数据库表等）。

目标受众 ：软件架构师和开发人员。

对大多数团队的建议 ：不，特别是对于长期存在的文档，因为大多数 IDE 可以根据需要生成这种级别的详细信息。

C4 模型提供了单个软件系统 的静态视图 ，但在现实世界中，软件系统永远不会孤立存在。 因此，特别是如果您负责软件系统的集合/组合，了解所有这些软件系统如何在给定的企业、组织、部门等中组合在一起通常很有用。本质上，这是一张地图所选范围内的软件系统，并对每个感兴趣的软件系统进行 C4 深入分析。

从实践的角度来看，系统景观图实际上只是一个系统上下文图，没有具体关注特定的软件系统。

范围 ：企业/组织/部门/等。

主要元素 ：与所选范围相关的人员和软件系统。

目标受众 ：软件开发团队内部和外部的技术人员和非技术人员。

当您想要显示静态模型中的元素如何在运行时协作以实现用户故事、用例、功能等时，动态图可能很有用。该动态图基于 UML 通信图（以前称为“UML ” ）协作图”）。 它类似于 UML 序列图 ，尽管它允许图元素的自由形式排列，并通过编号的交互来指示顺序。

范围 ：特定功能、故事、用例等。

主要和支持元素 ：您的选择 - 您可以显示在运行时交互的软件系统、容器或组件。

目标受众 ：软件开发团队内部和外部的技术人员和非技术人员。

注意 ：如果您喜欢 UML 序列图的视觉风格，请随意使用它。

部署图允许您说明静态模型中的软件系统和/或容器的实例如何部署到给定 部署环境 （例如生产、登台、开发等）内的基础设施上。 它基于 UML 部署图 。

部署节点 代表 软件系统/容器实例运行的位置； 也许是物理基础设施（例如物理服务器或设备）、虚拟化基础设施（例如 IaaS、PaaS、虚拟机）、容器化基础设施（例如 Docker 容器）、执行环境（例如数据库服务器、Java EE Web/应用程序服务器、 Microsoft IIS)等。部署节点可以嵌套。

您可能还希望包括 基础设施节点 ，例如 DNS 服务、负载均衡器、防火墙等。

请随意使用 Amazon Web Services、Azure 等提供的图标来补充您的部署图...只需确保您使用的任何图标都包含在您的图表键/图例中即可。

范围 ：单个部署环境（例如生产、登台、开发等）内的一个或多个软件系统。

主要元素 ：部署节点、软件系统实例和容器实例。
支持元素 ：软件系统部署中使用的基础设施节点。

目标受众 ：软件开发团队内外的技术人员； 包括软件架构师、开发人员、基础设施架构师和运营/支持人员。

人

软件系统

容器

组件

关系

图表

• 每个图都应该有一个描述图类型和范围的标题（例如“我的软件系统的系统上下文图”）。
• 每个图表都应该有一个图例/图例来解释所使用的符号（例如形状、颜色、边框样式、线条类型、箭头等）。
• 首字母缩写词和缩写词（业务/领域或技术）应为所有受众所理解，或在图表键/图例中进行解释。

元素

• 应明确指定每个元素的类型（例如，人员、软件系统、容器或组件）。
• 每个元素都应该有一个简短的描述，以提供关键职责的“一目了然”的视图。
• 每个容器和组件都应该有明确指定的技术。

人际关系

• 每条线都应该代表单向关系。
• 每行都应该有标签，标签与关系的方向和意图（例如依赖性或数据流）一致。 标签尽量具体，最好避免使用“用途”等单一单词。
• 容器之间的关系（通常代表进程间通信）应该有明确标记的技术/协议。