C4架构模型在软件设计中的应用

在软件开发过程中，文档的编写是一个不可或缺的环节。然而，过多的文档可能会拖慢团队的进度。因此，需要创建既提供价值又不会阻碍团队进展的文档。C4架构模型就是这样一种工具，它是一个静态模型，能够以一种简单的方式向所有相关人员传达系统的设计，并且为探索软件解决方案的架构提供了一种自然的叙述方式。从最高级别（系统是什么以及它如何为业务提供价值）开始，逐步深入到细节，直到功能级别的最低级别。

C4模型由Simon Brown创建，可以在他的网站上找到更多的细节和现场演示。C4模型是一种分层的方式来思考软件系统的结构。尽管存在UML或4+1架构视图等其他方法，但C4模型仍然具有以下优势：

• 使图表易于阅读
• 具有缩放功能，提供不同级别的细节，更适合项目中不同角色的人员
• 减少设计与实际实现之间的差距

为了尝试这个模型，建议从一个简单的规范开始，最初是为架构kata会议设计的。在本文中，将更多地关注如何图形化地表示系统，而不是讨论系统的设计效果如何。

C4模型 - 图表

上下文图 上下文图是一个简单的块图，显示了软件系统作为一个中心的盒子，周围是它的用户和其他与之交互的软件系统。这里的细节并不重要，因为这是放大的视图，显示了系统环境的大局。重点应该放在人（参与者、角色、角色等）和软件系统上，而不是技术、协议和其他低级细节。这是可以向非技术人员展示的那种图表。

上下文图提供了大局观，并回答了以下问题：

1. 正在构建的软件系统是什么？
2. 谁在使用它？
3. 它如何适应现有环境？

容器图 这是一个简单的、高层次的技术焦点图。它是软件架构的高层次形状，显示了责任是如何在其中分配的。这个图表回答了以下问题：

1. 软件系统的整体形状是什么？
2. 高层次的技术决策是什么？
3. 责任是如何在系统中分配的？
4. 容器之间如何通信？
5. 作为开发者，需要在哪里编写代码以实现功能？

组件图 下一步是进一步分解容器，展示内部组件。这组图表应该回答以下问题：

1. 系统由哪些组件/服务组成？
2. 系统在高层次上是如何工作的？
3. 所有组件/服务都有归属吗？（即，它们是否位于一个容器中？）

类图 为了保持简单，这个级别的图表仅用于说明特定细节。这些是标准的UML图表，可以用许多工具生成。这里有一个从LucidChart工具提供的样本开始的小样本。

共同理解和知识

这个模型可以被一个或多个团队使用，这些团队构建或维护产品或软件项目，可以产生共同的理解。使用相同的图表，团队成员开始使用相同的词汇，提供了更好的机会来关联彼此的知识和专业知识。最终，这是成功团队的核心优势。