如何画好一张架构图？

阿里妹导读：架构图是什么？为什么要画架构图？如何画？有哪些方法？本文从架构的定义说起，分享阿里文娱高级技术专家箫逸关于画架构图多年的经验总结，并对抽象这一概念进行了深入地讨论。较长，同学们可收藏后再看。

什么是架构图？

如何画好一张架构图，要做好这件事情首先要回答的就是什么是架构图。我们日常工作中经常能看到各种各样的架构图，而且经常会发现大家对架构图的理解各有侧重。深入追究到这个问题，可能一下子还很难有一个具象的定义，如果我们把这个问题进行拆分（如下图）理解起来就会容易一点。

架构图 = 架构 + 图

按照这个等式，我们可以把问题转换：

• 架构是什么？
• 图是什么？

图是什么？这个比较容易回答，图是一种信息的表达方式，所以架构图，即表达“架构”的图，也就是一种架构的表达方式。也即：

架构图 = 架构的表达 = 表达架构的图

按照这种思路我们需要回答：

• 什么是架构？要表达的到底是什么？
• 如何画好一张架构图？

接下来的内容基本上就是按照这两个维度来做分析。

什么是架构？要表达的到底是什么？

Linus 03 年在聊到拆分和集成时有一个很好的描述：

I claim that you want to start communicating between independent modules no sooner than you absolutely HAVE to, and that you should avoid splitting things up until you really need to, because that communication complexity often swamps the complexity of the actual pieces involved in it.（让我们认识到一种现象，把复杂系统拆分成模块，似乎并没有降低整个系统的复杂度。它降低的只是子系统的复杂度。而整个系统的复杂度，反而会由于拆分后的模块之间，不得不进行交互，变得更加复杂。）

我理解这里描述的系统拆分就是架构的过程，基本出发点是为了效率，通过架构的合理拆分（无论是空间还是时间上的拆分），最终目的让效率最大化。那到底什么是架构，其实没有完全统一且明确的定义，如下三个定义可以参考。

在百度百科上的定义：

架构，又名软件架构，是有关软件整体结构与组件的抽象描述，⽤于指导⼤型软件系统各个方面的设计。

在 Wikipedia 上的定义：

Architecture is both the process and the product of planning, designing, and constructing buildings or any other structures.

ISO/IEC 42010:20072 中对架构有如下定义：

The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

这三个定义也是见仁见智，但是我们基本可以得出：架构体现的是整体结构和组件之间的关系。

架构的本质

这里引用三个观点来探讨架构的本质：

• 架构的本质是为了管理复杂性。
• 架构的本质就是对系统进行有序化重构，不断减少系统的“熵”，使系统不断进化。
• 架构的本质就是对系统进行有序化重构，以符合当前业务的发展，并可以快速扩展。

上述三个观点提到的内容，基本表达了架构的核心目的：管理复杂性，效率最大化。以及架构的两个主要变化来源：一个是以改善软件质量为目的的内在结构性变化；另外一个是以满足客户需求为目的的外在功能性变化。无论是何种变化，在我看来架构都是在不断的判断和取舍，在业务需求和系统实现之间做权衡，从而来应对未来变化的不确定性，如下图可以比较粗浅直观的表达这种理解。

要表达的是什么？

在 EA 架构领域，有两种常见架构方法 RUP 和 TOGAF，这两个框架也是我们常常了解架构分类的两个维度。从个人的角度，我自己觉得 TOGAF 的分类方式更加广泛使用（如下右图）。

结合日常的业务开发，其实我们更多的是关注业务架构和应用架构，所以把上边的表达式进一步的拆解，在回答如何画好一张架构图之前，我们需要关注业务架构和系统架构，讨论清楚如何进行业务架构和系统架构。

架构的过程其实就是建模的过程

我们都知道现实世界到软件世界或者面向对象的世界的过程，是一个不断抽象的过程，这其中的方法就是不断的建立模型。从现实世界到业务模型，从业务模型到概念模型，从概念模型到设计模型，通过不断的抽象去粗取精，形成对现实世界的层层抽象，所以架构的过程其实就是建模的过程。至此，我们有必要了解一下什么是建模。

百度百科定义：

建模就是建立模型，就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。

《Thinking in UML》定义：

建模（Modeling），是指通过对客观事物建立一种抽象的方法用以表征事物并获得对事物本身的理解，同时把这种理解概念化，将这些逻辑概念组织起来，构成一种对所观察的对象的内部结构和工作原理的便于理解的表达。

从上述两个定义上基本可以了解到建模就是抽象，对业务或现实世界的抽象，虽然不足以帮我们理解架构本身，但是可以将我们上述关注的业务架构和系统架构进一步向下 Down 一层，架构的过程是建模的过程，我们转换成两个简单的问题：模是什么？如何建？

模是什么？如何建？

这是两个比较容易陷入理论性的问题，我们跳出来从结果看过程。接下来通过已经产出的一些架构图来反向看这些架构图是如何产出的，同时来回答这两个问题。