软件架构是什么？为什么架构很重要？如何设计架构？上篇中解答了这灵魂三问。但这还远远不够。下篇的分享从如何用图去描述（describe）和传达（communicate）你的架构设计开始，聊工具和方法。值得强调的是，单一的方法和工具不是我们关注重点，优秀方法背后的通用方法论，即架构制图的本质、共性和最佳实践更有意义。

怎么描述你的架构设计？

任何没有持久化的东西都是易失的（volatile），就跟内存一样。另一方面，就如前文所述，架构是沟通协作的基础，通过架构描述（Architecture Description）沉淀下来让所有项目干系人都能看到，就不会失去了沟通和传播的唯一载体。

• 架构描述的方式

对于同一件事物，作家会选择用文字来叙述，而画家却会用图画。尽管两者想要传达的信息是一致的，但描述方式的不同也会带来效果上的巨大差异。架构描述也分文字（Text）和图（Diagram）两种形式，两者各有千秋：

• 文字的背后是由一套严谨和完备的语言作为支撑，因此其描述可以做到非常精准和详尽，而且编写起来也很方便，随便打开个记事本软件都能写；此外，就跟写代码一样，文字很易于做版本管理，借助简单的文本 diff 工具就能一目了然地对比出不同版本之间的细节差异；
• 相比而言，图并不具备以上文字所独有的特点，但也有自己的独特优势：图是直观而形象的，顺应了人类与生俱来的视觉识别本能；图的表达能力更强，很多时候一小张图所能传达出的信息（比如空间位置关系、颜色分类、图标形状），也许用一千行字也不足以完整准确地描述出来，即所谓“一图胜千言”。

在如今这个全面敏捷开发的时代，如何也顺应潮流更加敏捷地编写架构文档呢？ROI is your friend —— 不求多，但求精，尽量用最少的笔墨表达出最核心的内容。从内容上来说，ROI 高的部分一般是偏顶层的整体架构或最核心的关键链路。而从形式上来说，图在文字面前具有无与伦比的表达力优势，显然是 ROI 更高的选择。不过制图也不简单，架构制图与工程制图一样，都是一件需要下功夫认真严谨对待的事情

讨论具体的制图方法和工具前，我们需要先竖立清晰的制图目标。形形色色的方法与工具本质上都是想把制图这个过程从一门自由的手艺变成一项科学的工程：系统、严谨、完整、标准化，同时能做到可重复、可持续和高效。

架构制图方法与工具

• 方法一：UML

UML 应该是大部分人最熟悉的制图方法了，最新的 UML 2.x 版本由以下两大类图组成：

结构图（Structural Diagrams）—— 通过对象、属性、操作和关系等方式，强调系统的静态结构，其中最常见的类型包括类图（Class Diagram）、组件图（Component Diagram）和部署图（Deployment Diagram）；

行为图（Behavioral Diagrams）—— 通过展示对象之间的协作关系以及对象内部的状态改变，强调系统的动态行为，其中最常见的类型包括用例图（Use Case Diagram）、活动图（Activity Diagram）、时序图（Sequence Diagram）和状态机图（State Machine Diagram）。

• 方法二：4+1 View Model

“4+1”是一种视图模型（view model），可以通过多种共存的视图描述软件密集型系统的架构。这些视图基于不同项目干系人（利益相关者）的视点（viewpoint），例如：终端用户、开发者、系统工程师和项目经理。“4+1”由 4 种基础视图和一些经过挑选的用例或场景（即额外的“+1”视图）组成，各自的具体含义如下：

逻辑视图（Logical view）—— 描述系统为终端用户提供的功能，一般会通过UML中的类图和状态图来表示；

过程视图（Process view）—— 描述系统的动态行为，包括流程和交互等，一般会通过 UML 中的时序图、活动图和通讯图来表示；

开发视图（Development view）—— 从程序员的视角来阐述系统，也被称为“实现视图”，一般会通过 UML 中的组件图和包图来表示；

物理视图（Physical view）—— 从系统工程师的角度来描述系统，包括系统组件的物理拓扑、各组件之间的物理连接，也被称为“部署视图”，一般会通过 UML 中的部署图来表示；

场景（Scenarios）—— 通过一小组用例或场景来描述架构，包括系统中各种对象和进程之间的交互时序，也被称为“用例视图”。这些场景会被用于识别架构元素（architectural elements）以及阐述和验证整个架构设计，也可以被作为架构原型的测试起点。

• 方法三：C4 Model

C4 模型是一种“抽象优先”（abstraction-first）的架构制图方法，它也是受前面的 UML 和“4+1”视图模型所启发，但相对而言要更加简单和轻量，只包含少量的一组抽象和图表，很易于学习和使用。

• 方法四：arc42

严格来说， arc42并不是一种架构制图方法，而是一个架构文档模板。本质上 arc42 中提倡的制图方法与C4模型是等价和兼容的，完全可以配合使用：以 arc42 作为架构文档框架，其中的架构制图采用更具体的 C4 模型。

• 其他方法 & 制图工具

方法论总结

最后的最后，让我们试着对各种架构制图方法进行归纳总结。毕竟即便现在所熟知的各种方法与工具终会过时，也依然能风轻云淡地看待它们的新老交替：过去是 UML，现在是 C4，未来是什么呢？这并不关键，因为即使方法过时了，背后的方法论也不会过时。

• 理解制图目标

架构制图的第一要点，是需要先深刻理解制图目标。正所谓“以始为终”，有了目标我们才能清晰地前行；否则漫无目的地乱窜，往往会多走不少弯路，甚至南辕北辙。

• 找准受众和关注点

架构制图的第二要点，是要找准你制图的受众（audience）以及他们各自的关注点（concern）。找不准的话，要么效果大打折扣（不是他们想听的），要么犹如对牛弹琴（他们根本就听不懂）。

• 自顶向下逐层描述

架构制图的第三要点，是合理运用层次化（hierarchical）的套路，自顶向下逐层描述。无论是 C4 模型还是 arc42 模板，背后都深刻运用并显著强调了这一点。

分而治之——软件领域中，分而治之是控制和应对复杂系统的最有效方法。而层次化拆分，本质上就是一种分而治之手段：将系统按照从粗到细的粒度，一级一级地拆分成多个相对独立和低耦合的元素（子系统、应用、组件等）；

金字塔原理——这本书的核心观点就是，按照自顶向下的方式，先抛出主观点再依次用各个子观点去论证。这样的沟通方式更符合人类的思维逻辑，也更容易让读者接受。简单来说，就是要“先说重点”，帮助读者做归纳总结和划重点，而不是先抛出一大堆细枝末节的零散东西让读者自己去消化和推演。

• 使用多种架构视图

• 遵循规范和最佳实践

架构制图的第五要点，其实只是一句正确的废话：遵循规范和最佳实践。这一点已经不限于架构制图，而是上升到了工程实践领域的通用方法论层面。正如前面章节所说，“学习架构制图的目标，就是要把它从一门手艺变成一项工程”，因此架构制图的“施工”过程也理所应当符合工程化思维。

文章部分素材来源：阿里巴巴云原生