架构制图

前言

“架构制图”这词乍一听似乎有些晦涩，但如果提起“工程制图”，相信绝大部分工科背景的程序员们都不会陌生，甚至还能共同感慨下那些年一起伏在宿舍左手圆规，右手直尺，徒手作图到深夜的日子。
软件工程也是工程，因此传统工程制图的一些基本理论，在软件行业同样适用。但另一方面，软件与实体制造业之间还是有着本质区别，所以在制图方面的需求和方式也大相径庭，无法直接套用。作为软件行业的从业者，你可以完全不懂工程制图，但你不得不懂架构制图 —— 这是任何程序员职业生涯的的必修课。
本文在后半段将介绍如何用图去描述（describe）和传达（communicate）你的架构设计。值得强调的是，本文并不会侧重于单一的方法和工具，而是更希望关注那些优秀方法背后的通用方法论，即架构制图的本质、共性和最佳实践。希望本文能起到引子作用，激发大家对自己日常工作中关于架构和制图部分的关注、审视与思考；如果还真能帮助大家提升一点点制图效率和效果，那就更好不过了。

什么是软件架构？

1. 软件架构定义

IEEE 给出的定义：架构是环境中该系统的一组基础概念（concepts）和属性（properties），具体表现就是它的元素（elements）、关系（relationships），以及设计与演进的基本原则（principles）。
CMU 软件工程研究院的定义：架构是用于推演出该系统的一组结构（structures），具体是由软件元素（elements）、元素之间的关系（relationships），以及各自的属性（properties）共同组成。
Uncle Bob 在 Clean Architecture 一书中给出的定义：架构是创建者给予该系统的形态（shape）。这个形态的具体形式来源于对系统组件（components）的划分和排列，以及这些组件之间互相通讯的方式。

2. 架构核心要素

综合上述各种权威定义，软件系统的架构通常需要包含如下四类核心要素：

元素（elements）：将系统拆分为一组元素 - 模块、组件、结构体、子系统；
关系（relationships）：不同元素之间的关系 - 交互、依赖、继承、组合、聚合；
属性（properties）：每个元素具备的属性 - 名称、职责、接口、实现限制等；
原理（principles）：为什么这么设计 - 拆分依据、设计原则、决策原因等。

为什么架构很重要？

1. 架构是系统实现的蓝图

最近有部很火的网剧叫《摩天大楼》，讲述了一段匪夷所思的悬疑故事。为什么扯这个呢？因为我想借用这个剧的标题来问个问题：摩天大楼是由谁建起来的？也许你心里会默念：废话，不就是建筑工人们一砖一瓦堆起来的嘛。仔细再想想？背后是不是还有一堆操碎了心的建筑设计师（比如剧中帅气的林大森）和土木工程师们？他们虽然不搬砖也不扛水泥，但如果没有他们产出的那些繁琐严谨的设计图纸，摩天大楼是是不可能像农村自建房一样仅凭工人们各自的经验与想象力就能快速平稳地竖立起来的。
正是靠着这些图纸所描绘出来的工程蓝图（blueprints），才让成百上千工人们的分工合作和验收标准有了依据：大家只需要照着蓝图，按部就班地把自己所负责的那些砖瓦添上去就行了；只要蓝图正确，且施工过程也没有偏差，最终顺利完工只是个时间问题。
与建筑、汽车或者任何其他工程行业一样，软件在落地实现（编码）之前也需要先有蓝图；而其中最重要的一份蓝图，就是架构设计。没有架构，仅凭程序员自己脑子里的模糊设想，也许你可以像传统手艺人一样独自创造出一些美好有用的小东西（比如 Linux 0.01 版本），但不太可能以工程的方式协同一个团队共同建造起一个与摩天大楼规模类似的复杂软件系统（比如现代的 Linux 系统）。一方面，人类的思维能力终归有限，必须依靠架构这种高度抽象和简化的蓝图，才能让复杂系统的创造、理解、分析和治理变得可行；另一方面，量级达到一定程度的大型系统，也只能依靠多人分工合作才能完成，而架构也正是多人沟通协作的重要基础。

2. 架构是沟通协作的基础

软件项目的最终价值产出就是软件系统，而架构作为软件系统的灵魂和骨架，可以起到如下作用：

理解对齐：所有软件系统的目的都是为了实现用户需求，但实现的途径有无限种可能性（相比传统工程行业，软件的灵活性更大、知识迭代更快）。架构设计就是去选择其中一条最合适的实现途径，因此其中会涉及非常多关键的选路决策（为什么要这么拆分？为什么选择 A 技术而不是 B？）。这些重要的技术决策需要通过架构描述这种形式被记录和同步，才能让项目组所有成员对整个系统的理解对齐，形成共识。
工作量化：项目管理最重要的步骤之一就是工时评估，它是确定项目排期和里程碑的直接依据。显然，只通过 PRD / 交互图是无法科学量化出项目工作量的，因为很难直观判断出一句简短需求或一个简单页面背后，究竟要写多少代码、实现起来难度有多大。有了清晰明确的架构之后，理论上绝大部分开发工作都能做到可见、可预测和可拆解，自然而然也就能够被更准确地量化。当然，精准的工作量评估在 IT 行业内也一直是个未解之谜，实际的工期会受太多未知因素影响，包括程序员的技能熟练度、心情好不好、有没有吃饱等。
标准术语：编程作为一种具有创造力的工作，从某种角度看跟写科幻小说是类似的。好的科幻小说都喜欢造概念，比如三体中的智子，如果没看过小说肯定不知道这是个啥玩意儿。软件系统在造概念这一点上，相比科幻小说只有过之而无不及，毕竟小说里的世界通常还是以现实为背景，而软件中的世界就全凭造物者（程序员）的想象（建模）了。稍微复杂一点的软件系统，都会引入一些领域特定甚至全新创作的概念。为了避免在项目过程中出现鸡同鸭讲的沟通障碍和理解歧义，就必须对描述这些概念的术语进行统一。而架构的一个重要目的，就是定义和解释清楚系统中涉及的所有关键概念，并在整个架构设计和描述过程中使用标准和一致的术语，真正做到让大家的沟通都在一个频道上。

言之有物：就跟讨论产品交互时需要对着原型图、讨论代码细节时需要直接看代码一样，架构是在讨论一些较高维技术问题时的必要实物（具体的实物化形式就是所谓架构描述）。否则，要么一堆人对着空气谈（纸上谈兵都说不上），要么每次沟通时都重新找块白板画一画（费时费力且容易遗落信息，显然不是长久之计）。
知识沉淀 & 新人培训：架构应该被作为与代码同等重要的文档资产持续沉淀和维护，同时也是项目新人快速理解和上手系统的重要依据。不要让你的系统跟公司内某些祖传遗留系统一样 —— 只有代码遗留了下来，架构文档却没有；只能靠一些口口相传的残留设计记忆，苦苦维系着项目的生命延续。

3. 架构决定了产品质量

如何衡量一个软件产品的质量？上图是 ISO/IEC 25010 标准定义的软件产品质量模型，包括以下 8 个大类：

功能适合性：功能完整度、功能正确性和功能恰当性；
性能效率：时间表现（e.g. 响应时间）、资源利用和容量；
兼容性：共存能力（e.g. 多版本组件共存）和互操作性；
可用性：可学习性、可运维性、用户错误保护（e.g. 自动纠错）、UI 美观度、可访问性；
可靠性：成熟度、可用性、容错性、可恢复性；
安全性：机密性、完整性、不可伪造性、权威性和可审计；
可维护性：模块度、可复用性、可分析性、可修改性、可测试性；
可移植性：可适配性、可安装性、可替代性。

上述质量模型中列出的所有点，都是架构设计需要着重考虑的。其中除了功能适合性以外，其他所有点都属于非功能需求的范畴，这也是区分架构好坏的真正分水岭 —— 好的架构设计，不会停留在仅满足功能需求这一最基本的需求层次上（最坏的架构设计也同样能做到），更重要且更难以应对的是其他众多的非功能需求。

当然，鱼与熊掌不可兼得。架构与人生一样，也是一场权衡的游戏，弄不好就跟第八季的龙母一样的下场：既要又要还要，最后反而什么都得不到。好的架构师更应该像雪诺同志学习，表面上“know nothing”，实际上“know everthing”：清楚系统所有利益相关者（stakeholders），努力挖掘各方的主要述求（concerns），相应平衡自己的架构决策（decisions），最终实现你好我好大家好的终极架构目标。

4. 我还能说出更多理由

要不是篇幅所限，这一页 PPT 显然不够装：

架构包含系统所有最重要的早期决策，这些决策会进而影响后续所有大大小小的技术决策。因此，早期的架构设计需要非常严谨和慎重，要尽可能“一次做对”（虽然很难），否则越往后纠错的成本越高；

架构在组织内具有非常高的复用价值，因为同一组织内的产品之间一定会具备很多共性（需求、限制、环境等），很适合在架构层面进行最大化复用，避免重复解决相似的问题；

康威定律指出，软件架构反映了组织结构。这个结论反过来也成立：好的架构也会让组织结构变得更高效；

越庞大和复杂的系统，架构越重要，因为只有好的架构才能有效控制、管理和降低系统复杂度；
是不是越听越糊涂，仿佛架构有无数种诠释和意义？不必过于纠结，按照GoF的设计模式所述：Architecture is about the important stuff. Whatever that is. 对，管它是啥，记住架构很重要就够了。

怎么描述你的架构设计？

有了良好的架构设计，万里长征之路就已经走了一大半。就像是青年导演第一次遇上好剧本，心潮澎湃两眼放光，仿佛已经预见了电影上映后的票房盛况。当然，剩下的一小半路，并不会如想象中那么平坦 —— 同样的剧本，不同导演拍出来会有质一样的区别。好的“最佳导演”，即使面对不是“最佳剧本”的剧本，也有能力拍出“最佳影片”。同样，好的架构师，也应该有能力描述好一个不错的架构设计；即使做不到为精彩的内容加分，也不应该因为形式上没描述好而丢分，否则就会像高考作文丢了卷面分一样憋屈和心酸。

1. 架构描述的意义

为什么要描述架构？让它只存在我深深的脑海里不行吗？西方人有句谚语：好记性不如烂笔头。任何没有持久化的东西都是易失的（volatile），就跟内存一样。另一方面，就如前文所述，架构是沟通协作的基础，不通过架构描述（Architecture Description）沉淀下来让所有项目干系人都能看到，那就失去了沟通和传播的唯一载体。

根据个人观察，大家对“架构需要描述”这一点都没异议，所以绝大部分项目都或多或少会产出一些有模有样的架构描述文档。但“有架构描述”和“有好的架构描述”，这之间的鸿沟是巨大的，甚至比“没有”和“有”之间的差别还大。如果你也跟我一样，饱经沧桑阅尽无数架构文档，曾拍手叫好心怀感激过，也曾拍着大腿愤怒不已过，应该也能感同身受。

2. 架构描述的方式

对于同一件事物，作家会选择用文字来叙述，而画家却会用图画。尽管两者想要传达的信息是一致的，但描述方式的不同也会带来效果上的巨大差异。架构描述也分文字（Text）和图（Diagram）两种形式，两者各有千秋：
- 文字的背后是由一套严谨和完备的语言作为支撑，因此其描述可以做到非常精准和详尽，而且编写起来也很方便，随便打开个记事本软件都能写；此外，就跟写代码一样，文字很易于做版本管理，借助简单的文本 diff 工具就能一目了然地对比出不同版本之间的细节差异；
- 相比而言，图并不具备以上文字所独有的特点，但也有自己的独特优势：图是直观而形象的，顺应了人类与生俱来的视觉识别本能；图的表达能力更强，很多时候一小张图所能传达出的信息（比如空间位置关系、颜色分类、图标形状），也许用一千行字也不足以完整准确地描述出来，即所谓“一图胜千言”。
聪明的你冷笑了一声：哼，又不是小孩子非得做选择题，难道不可以文字与图都要吗？当然可以，理想的架构描述一定是图文并茂的。但现实世界显然比理想残酷，实际软件项目中很难给你留足时间先憋出一篇完美的架构文档。如果以成年人的思维去考虑投入产出比（ROI），那么你一定会优先选择画图。

3. 为什么你应该优先画图？

敏捷软件开发宣言中提到：相比详尽的文档，可运作的软件更加重要（Working software over comprehensive documentation）。这么说当然不代表就不用写文档了，只是提倡没必要写过于详尽的文档。为什么？因为详尽的文档需要耗费大量的编写和维护成本，不符合敏捷开发的小步迭代和快速响应变化等原则。

那么，在如今这个全面敏捷开发的时代，如何也顺应潮流更加敏捷地编写架构文档呢？ROI is your friend —— 不求多，但求精，尽量用最少的笔墨表达出最核心的内容。从内容上来说，ROI 高的部分一般是偏顶层的整体架构或最核心的关键链路，这点在后文的 C4 模型理念中也有体现。而从形式上来说，图在文字面前具有无与伦比的表达力优势，显然是 ROI 更高的选择。

4. 为什么你需要学习画图？

多画图是没错，但有必要专门学习吗？又不是素描彩笔水墨画，只是画一堆条条框框而已，稍微有点工程常识的都能上。画的有点丑？那没关系，顶多再动用点与生俱来的艺术美感，把这几条线对对齐那几个框摆摆正，再整点五彩斑斓的背景色啥的，不就显得很专业了嘛？

看到这里，屏幕前的你又轻蔑一笑：哼，显然没这么简单。确实，道理说出来大家都懂，架构制图与工程制图一样，都是一件需要下功夫认真严谨对待的事情。但现实中大部分人还真没这工夫去下那功夫，比如上面贴的两幅很常见的架构图。第一张图不用多说，这种草图自己涂涂抹抹挺好，但拿出来见人就是你的不对了。那第二张图呢，看上去似乎还挺像那么回事的？并不是，如果你更仔细地去揣摩，就能发现这张图底下所隐藏的很多模糊和不严谨之处（可参考这张图的来源文章：The Art of Crafting Architectural Diagrams）。

所以，能画图并不代表能画好图；要想制得一手既漂亮又可读的好图，还是需要经过持续学习与刻意练习的，很难仅凭直觉和悟性就能掌握其中的关键要领。此外，错误的图往往比没有图还要糟糕，即使你只是抱着“有图就行，差不多那个意思得了”的心态，也至少应该理解一些科学制图的关键要素，避免给本来就已经很复杂难做的项目又蒙上一层模糊滤镜，甚至起到混淆和误导的反作用。

5. 架构制图的目标

讨论具体的制图方法和工具前，我们需要先竖立清晰的制图目标。工具是人类进化的阶梯，但如果理解和利用不当，则很容易反过来被工具所限制甚至奴役，忘了最初发明和使用工具的初心。对于架构制图而言，已经有那么多形形色色的方法与工具，使用它们的初心是什么呢？我认为本质上都是想把制图这个过程从一门自由的手艺变成一项科学的工程：系统、严谨、完整、标准化，同时能做到可重复、可持续和高效。
转载于：https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247494834&idx=1&sn=3a94a4dce52e6e0fe4b1351cb700ed3e&chksm=fae6e77dcd916e6b294a22fcdf36e0c57874706aebe3b2576f2b93e02019663ee5546740d2d4&token=1124631645&lang=zh_CN