软件架构图该怎么画？架构设计如何标准化？

本文试图回答以下问题：

1. 如何标准化软件架构设计/li>
2. 如何把软件架构设计拆解成一个个小任务，渐进完成，辅助敏捷开发/li>
3. 如何共享软件架构设计内容，让团队成员都能更新，而不只是存在于架构师的PPT里/li>

五花八门的软件架构图

如果上网搜索系统架构图，我们会看到各种形式的架构图，没有统一的标准。有的画得很粗，主要描述的是系统和系统之间的交互方式。有的画的很细，使用 UML 画出了类图。这些设计图要么只能看到树木，不见森林，要么只见森林不见树木，中间缺乏过渡。基于这样的设计图只能回答部分软件设计问题，由于缺乏标准，除非有详细的文字说明，否则光看设计图难以理解设计意图。

由于有这种明确的分层拆解，C4 Model 可以让团队按照 MVP 原则分步实现软件架构设计，辅助敏捷开发。比如在设计完系统上下文图以后，团队成员可以按照其中的待设计系统，得到几个容器图设计任务，然后根据容器图中容器的优先级，设计组件，以此类推。

第一层: 系统上下文图 (System Context Diagram)

系统上下文图要回答的问题是本系统和其他系统之间的关系，这种关系可能是本系统依赖于其他系统也可能是其他系统依赖本系统。系统上下文图是 C4 Model 中最高层级的设计图，它一般包括以下几个标记：

• 人 (Person)
• 准备开发的系统 (Software Systems)
• 外界系统或者已有系统 (Existing Systems)

下图表示的是“影院销售系统”系统上下文设计，其中 Person 的标记是“观众”。“观众”通过待开发的“影院销售系统”查看影片，选座和购买电影票。“影院销售系统”通过外界的“第三方支付系统”完成收款，通过“短信系统”向“观众”发送购票短信。

第三层: 组件图 (Component Diagram)

组件图是容器图的下一层。它要回答的问题是某个容器内部由哪些组件构成以及它们之间的关系。

下图是我们对容器图中的 “API服务”的详细设计，可以看到“API 服务”由 “Ticketing Controller”， “Seating Controller”, “Movie List Controller”, “Messaging Component” 和 “Payment Component” 等5个组件构成。”Ticketing Controller”使用 “Messaging Component”发送短信，使用 “Payment Component”完成第三方支付。”Messaging Component”会调用“短信服务”发送取票码短信，”Payment Component”会调用”第三方支付系统”完成支付。

从这个例子我们可以看到 C4 Model 可以表示各层组件之间的关系，不仅仅是上一层，充分展现微观和宏观之间的联系，表达设计意图。

结论

C4 Model 提供了一套 4 层架构设计模型和工具。它为我们标准化架构设计工作提供了思路。对敏捷团队而言使用这一模型可以实现架构设计任务的拆分，让小组成员共同参与到架构设计中来，辅助敏捷开发。

需要指出的是， C4 Model 是一套相对简单的架构设计模型，在各层设计中还应该跟诸如“领域驱动开发 (DDD)” 这样的方法论结合起来才能保证设计质量。另一方面，C4 Model 和许多架构设计图一样只是使用连线简要表达了各个组件之间的关系，没有完整的调用流程。笔者建议在各层之间使用 UML 序列图、状态图等说明组件调用的关系，以便于开发者理解和验证组件之间的联系和边界。

参考链接

• C4 Model 绘制网站
• 开源绘图工具
• Visual Studio Extension

来源：surfirst