“架构制图”这词乍一听似乎有些晦涩，但如果提起“工程制图”，相信绝大部分工科背景的程序员们都不会陌生，甚至还能共同感慨下那些年一起伏在宿舍左手圆规，右手直尺，徒手作图到深夜的日子。
软件工程也是工程，因此传统工程制图的一些基本理论，在软件行业同样适用。但另一方面，软件与实体制造业之间还是有着本质区别，所以在制图方面的需求和方式也大相径庭，无法直接套用。作为软件行业的从业者，你可以完全不懂工程制图，但你不得不懂架构制图——这是任何程序员职业生涯的的必修课。
IEEE给出的定义：架构是环境中该系统的一组基础概念（concepts）和属性（properties），具体表现就是它的元素（elements）、关系（relationships），以及设计与演进的基本原则（principles）。
CMU软件工程研究院的定义：架构是用于推演出该系统的一组结构（structures），具体是由软件元素（elements）、元素之间的关系（relationships），以及各自的属性（properties）共同组成。
综合上述各种权威定义，软件系统的架构通常需要包含如下四类核心要素：
最近有部很火的网剧叫《摩天大楼》，讲述了一段匪夷所思的悬疑故事。为什么扯这个呢？因为我想借用这个剧的标题来问个问题：摩天大楼是由谁建起来的？也许你心里会默念：废话，不就是建筑工人们一砖一瓦堆起来的嘛。仔细再想想？背后是不是还有一堆操碎了心的建筑设计师（比如剧中帅气的林大森）和土木工程师们？他们虽然不搬砖也不扛水泥，但如果没有他们产出的那些繁琐严谨的设计图纸，摩天大楼是是不可能像农村自建房一样仅凭工人们各自的经验与想象力就能快速平稳地竖立起来的。
与建筑、汽车或者任何其他工程行业一样，软件在落地实现（编码）之前也需要先有蓝图；而其中最重要的一份蓝图，就是架构设计。没有架构，仅凭程序员自己脑子里的模糊设想，也许你可以像传统手艺人一样独自创造出一些美好有用的小东西（比如Linux0.01版本），但不太可能以工程的方式协同一个团队共同建造起一个与摩天大楼规模类似的复杂软件系统（比如现代的Linux系统）。一方面，人类的思维能力终归有限，必须依靠架构这种高度抽象和简化的蓝图，才能让复杂系统的创造、理解、分析和治理变得可行；另一方面，量级达到一定程度的大型系统，也只能依靠多人分工合作才能完成，而架构也正是多人沟通协作的重要基础。
软件项目的最终价值产出就是软件系统，而架构作为软件系统的灵魂和骨架，可以起到如下作用：
如何衡量一个软件产品的质量？上图是ISO/IEC25010标准定义的软件产品质量模型，包括以下8个大类：
上述质量模型中列出的所有点，都是架构设计需要着重考虑的。其中除了功能适合性以外，其他所有点都属于非功能需求的范畴，这也是区分架构好坏的真正分水岭——好的架构设计，不会停留在仅满足功能需求这一最基本的需求层次上（最坏的架构设计也同样能做到），更重要且更难以应对的是其他众多的非功能需求。
要不是篇幅所限，这一页PPT显然不够装：
理解了架构的概念和重要性后，真正的架构师修炼之路才刚刚开始。如何设计一个好的架构？这显然是一个非常博大精深的主题，但并不是本文的重点，因此这里只简单列举了一些基本思想（原则）和经典套路（模式）。当然，架构设计更接近一门经验学科，仅停留在能脱口而出一些玄乎而高大上的理论概念肯定是不够的，需要结合实际工作内容和业务场景多多实践和揣摩才行，否则只能算是徘徊在架构的门外，连入门都谈不。
SOLID原则是一套比较经典且流行的架构原则（主要还是名字起得好）：
此外，我们做架构设计时也会尽量遵循如下一些原则（与上述SOLID原则在本质上也是相通的）：
架构模式（architecturalpatterns）与我们常讨论的设计模式（designpatterns）并不是一码事，但如果仅从“模式”这个角度去解读，两者的理念都是一致的：针对给定上下文中经常出现的问题的通用、可复用的解决方案。最主要的区别在于，架构模式会更高维抽象和偏全局整体（毕竟是运用在架构设计层面）。
常见的架构模式，既包括一些传统模式（e.g.分层、C/S、MVC、事件驱动），也包括一些新兴玩法（e.g.云原生、微服务、Serverless）。不同模式有不同的适用场景，没有哪一种模式能通杀所有需求。成熟的架构师应该像一个冷静到冒得感情的杀手，永远只会客观地评估和选择最适合当下的解决手段，即使那么做会显得简单乏味；相反，不成熟的架构师，一心总想着搞事情（e.g.强行套用微服务架构），而不是真正搞定问题。
有了良好的架构设计，万里长征之路就已经走了一大半。就像是青年导演第一次遇上好剧本，心潮澎湃两眼放光，仿佛已经预见了电影上映后的票房盛况。当然，剩下的一小半路，并不会如想象中那么平坦——同样的剧本，不同导演拍出来会有质一样的区别。好的“最佳导演”，即使面对不是“最佳剧本”的剧本，也有能力拍出“最佳影片”。同样，好的架构师，也应该有能力描述好一个不错的架构设计；即使做不到为精彩的内容加分，也不应该因为形式上没描述好而丢分，否则就会像高考作文丢了卷面分一样憋屈和心酸。
为什么要描述架构？让它只存在我深深的脑海里不行吗？西方人有句谚语：好记性不如烂笔头。任何没有持久化的东西都是易失的（volatile），就跟内存一样。另一方面，就如前文所述，架构是沟通协作的基础，不通过架构描述（ArchitectureDescription）沉淀下来让所有项目干系人都能看到，那就失去了沟通和传播的唯一载体。
根据个人观察，大家对“架构需要描述”这一点都没异议，所以绝大部分项目都或多或少会产出一些有模有样的架构描述文档。但“有架构描述”和“有好的架构描述”，这之间的鸿沟是巨大的，甚至比“没有”和“有”之间的差别还大。如果你也跟我一样，饱经沧桑阅尽无数架构文档，曾拍手叫好心怀感激过，也曾拍着大腿愤怒不已过，应该也能感同身受。
对于同一件事物，作家会选择用文字来叙述，而画家却会用图画。尽管两者想要传达的信息是一致的，但描述方式的不同也会带来效果上的巨大差异。架构描述也分文字（Text）和图（Diagram）两种形式，两者各有千秋：
敏捷软件开发宣言中提到：相比详尽的文档，可运作的软件更加重要（Workingsoftwareovercomprehensivedocumentation）。这么说当然不代表就不用写文档了，只是提倡没必要写过于详尽的文档。为什么？因为详尽的文档需要耗费大量的编写和维护成本，不符合敏捷开发的小步迭代和快速响应变化等原则。
那么，在如今这个全面敏捷开发的时代，如何也顺应潮流更加敏捷地编写架构文档呢？ROIisyourfriend——不求多，但求精，尽量用最少的笔墨表达出最核心的内容。从内容上来说，ROI高的部分一般是偏顶层的整体架构或最核心的关键链路，这点在后文的C4模型理念中也有体现。而从形式上来说，图在文字面前具有无与伦比的表达力优势，显然是ROI更高的选择。
多画图是没错，但有必要专门学习吗？又不是素描彩笔水墨画，只是画一堆条条框框而已，稍微有点工程常识的都能上。画的有点丑？那没关系，顶多再动用点与生俱来的艺术美感，把这几条线对对齐那几个框摆摆正，再整点五彩斑斓的背景色啥的，不就显得很专业了嘛？
所以，能画图并不代表能画好图；要想制得一手既漂亮又可读的好图，还是需要经过持续学习与刻意练习的，很难仅凭直觉和悟性就能掌握其中的关键要领。此外，错误的图往往比没有图还要糟糕，即使你只是抱着“有图就行，差不多那个意思得了”的心态，也至少应该理解一些科学制图的关键要素，避免给本来就已经很复杂难做的项目又蒙上一层模糊滤镜，甚至起到混淆和误导的反作用。
讨论具体的制图方法和工具前，我们需要先竖立清晰的制图目标。工具是人类进化的阶梯，但如果理解和利用不当，则很容易反过来被工具所限制甚至奴役，忘了最初发明和使用工具的初心。对于架构制图而言，已经有那么多形形色色的方法与工具，使用它们的初心是什么呢？我认为本质上都是想把制图这个过程从一门自由的手艺变成一项科学的工程：系统、严谨、完整、标准化，同时能做到可重复、可持续和高效。
P.S：当时做PPT太赶，所以从这个章节开始的配图，只能被迫走极简路线了，还请见谅。。。
经过前面几个章节的“简短”铺垫，相信大家对架构制图的背景知识都已经产生了足够的认知。本章节将会具体列举和描述一些典型的架构制图方法与工具，其中有常见的也有罕见的，重点是希望能通过各种方法的横向对比，加深大家对制图方法本质的理解。
UML应该是大部分人最熟悉的制图方法了，最新的UML2.x版本由以下两大类图组成：
作为通用的“统一建模语言”，UML总共包含了14种不同类型的图，可以全面覆盖软件设计领域各种制图需求，当然也包括了架构制图。同时，也正是因为UML把自己当成了一门语言，因此其各种记号（notion）和语义（sematics）都有非常严谨的定义，不会出现模糊或者歧义问题。最后，UML经过几十年的发展和推广，也早已成为世界范围内广泛使用的标准规范，其所带来的的隐性价值就是：在团队内使用UML进行沟通的成本是比较低的，因为可以假定绝大部分技术人员都能理解UML的含义和用法。
然而，UML也非万能（虽然历史上曾一度把它当成软件设计的银弹），它最被人诟病的缺点就是过于复杂。这也不能怪UML，毕竟它就是要被设计为足够通用、严谨和强大的，这些目标都与“简单”背道而驰，并让它一步步演化到了今天这个复杂刻板的庞然大物模样。虽然上面我们自信地假定了技术人员大多都懂UML，但这个“懂”如果带上一个程度量词，我觉得平均能到20%就不错了——绝大部分也就能认识几个常见的类图、时序图，估计都很难准确说出类图中各种箭头的含义。
无论怎么说，UML依然应该是每个程序员的制图工具箱中最常用和必备的工具之一。当然，也不应该是唯一，因为下面也还有些不能错过的好东西。
“4+1”是啥？不知道没关系，听过“6+1”吗？对，就是那个小时候常看的“非常6+1”节目。它跟“4+1”之间的关系，就跟它们与邵佳一、张嘉译和沈佳宜之间的关系一样，除了赶巧共用了同一个后缀发音以外，八竿子打不着。
C4模型是一种“抽象优先”（abstraction-first）的架构制图方法，它也是受前面的UML和“4+1”视图模型所启发，但相对而言要更加简单和轻量，只包含少量的一组抽象和图表，很易于学习和使用。
上面的左图展示了C4模型中各层次抽象之间的映射关系：1个软件系统由1~N个容器组成，1个容器由1~N个组件组成，1个组件由1~N个代码结构组成。右图是以简单的SpringPetClinic项目为例，演示了一个真实软件系统在C4模型下的层次结构：最上层就是PetClinic软件系统，它可以拆分为数据库、Web应用等几个容器；Web应用又可以进一步拆分出ClinicService这个组件，而这个组件下又包含了ClinicService接口类、ClinicServiceImple实现类、Owner/Pet/Visit等领域对象类。
使用C4模型进行架构制图，本质上就是对上述几种抽象进行可视化。具体的做法是依次建立如下几类从粗到细的结构图：Context、Container、Component和Code（可选），这也是C4模型名称的来历。
系统上下文图作为第一级（L1），提供了一个展示系统全貌的顶层大图（bigpicture）视角，包括最中心的软件系统、周边的用户以及其他有交互的系统。其中最关键的两个概念分别是：
在绘制系统上下文图时，不需要关心诸如技术栈、协议等任何底层细节。这类图的受众是最广的，因为任何人都可以理解并从中获取到足够的信息，包括技术人员和非技术人员，也包括团队内成员和团队外成员。
通过L1的上下文图理解了系统在整个IT环境中的定位后，下一步就是把系统这个框框放大，详细看下其中包含了哪些“容器”（Container，注意不要跟Docker容器搞混了噢！）。C4模型中的容器是指单个应用或数据存储，通常可以独立部署和运行（有独立的进程空间，通过IPC机制互相通讯），例如：SpringBoot微服务、ReactSPA、移动App、数据库、Serverlss函数、Shell脚本。
L2的容器图不仅展示了系统的进一步职责拆分，还包括了主要的技术选型、容器之间的通讯方式等关键架构信息。这类图可以面向全部的技术人员，既包括架构师、开发者，也包括运维人员、技术支持等。
与容器图类似，L3的组件图也不只包含了容器的组件划分，还包括各个组件的职责定义、技术与实现细节等。随着层次的下沉和细节的增多，组件图的受众范围进一步缩窄，一般只适用于软件架构师和开发者（其他角色没必要理解，一般也理解不了）。
再继续对组件进行放大，所能看到的最底层和细节的信息，就是L4的代码（Code）了。当然，这里所谓的“代码”还是以图的形式（e.g.UML类图、数据库E/R图）展示类或文件粒度的代码结构，并不是真正的代码本身。即便如此，代码图在99%的架构描述场景下也依然过于详尽，一方面数量庞大，绘制成本很高；另一方面易于变化，维护成本也非常高。因此，一般只有非常重要和复杂的组件才需要用到这一层级进行描述。如果确实需要绘制，也应该优先考虑自动化的方式，比如很多IDE就支持自动生成UML类图。
除了上述各个层次的静态结构图，C4模型还提出了一系列的补充图（Supplementarydiagrams），包括：
结合了这些补充图后的C4模型，才是可以全面与立体地描述出软件架构方方面面的完全体架构制图方法。
因此，本质上arc42中提倡的制图方法与C4模型是等价和兼容的，完全可以配合使用：以arc42作为架构文档框架，其中的架构制图采用更具体的C4模型。这也是目前我们项目中实际采用的方法。
到这里为止，本章节介绍的都是架构制图的各种方法；而实际从方法到落地的过程中，还有一个绕不开的环节：选用什么样的工具去制图？总不能真的跟写工程制图作业一样用纸和笔吧？作为数字化改革的推动者，程序员们当然要全面拥抱数字化工具；大家日常工作中必然也已经积累了很多顺手的画图工具，因此这里我只推荐两个自己用得比较多的：
古有云：授人以鱼，不如授人以渔。推而广之：授人以方法，也不如授人以方法论。什么是方法论？虽然这个词在公司里已经用烂了，但确实有它的价值和意义：方法论（methodology）是对方法的更高维度抽象，由它可以推导出解决问题的具体方法（method）。理解了方法论，才能融会贯通，掌握解决问题的本质要点；你也不会再受限于单一的具体方法，因为使用任何方法都能快速上手和灵活运用，并得到差不多的同等效果。
因此，本文最后这一章节将对各种架构制图方法进行归纳总结，并尝试提炼出一个通用的架构制图方法论，期望能帮助大家更好地理解架构制图背后的原理和思想。即便现在所熟知的各种方法与工具终会过时，也依然能风轻云淡地看待它们的新老交替：过去是UML，现在是C4，未来是什么呢？这并不关键，因为即使方法过时了，背后的方法论也不会过时。
所以，那些茫茫多的方法背后，究竟是什么样的核心方法论在支撑着呢？经过作者呕心沥血冥思苦想了近15秒钟，终于总结出了如下这套经典方法论（p.s：就是凑数的，不要太当真~）。由于其中包含了5个环环相扣的要点，我们姑且称它为：五环理论。
架构制图的第一要点，是需要先深刻理解制图目标。正所谓“以始为终”，有了目标我们才能清晰地前行；否则漫无目的地乱窜，往往会多走不少弯路，甚至南辕北辙。架构制图的目标是什么？其实前文已经提到过很多，这里再简单总结下：
架构制图的第三要点，是合理运用层次化（hierarchical）的套路，自顶向下逐层描述。无论是C4模型还是arc42模板，背后都深刻运用并显著强调了这一点。为什么一定要这么做？其中蕴含了两个普适的原理：
架构制图的第四要点，是在向传统的工程制图方法论致敬：使用多种架构视图来描述你的架构。在工程制图的世界里，任何立体的制品，大到机床小到零件，都至少需要通过三种视图（主视图、俯视图、左视图）来描述。作为现实世界的映射，软件系统也是多维和立体的，只用单一视图不可能覆盖所有关键的架构信息；即使强行把这些信息都塞在一张图里，那也一定会复杂到让人无法理解。
架构制图的第五要点，其实只是一句正确的废话：遵循规范和最佳实践。这一点已经不限于架构制图，而是上升到了工程实践领域的通用方法论层面。正如前面章节所说，“学习架构制图的目标，就是要把它从一门手艺变成一项工程”，因此架构制图的“施工”过程也理所应当符合工程化思维：
国际上对架构描述其实建立了专门的标准（ISO/IEC/IEEE42010:2011），其中的很多概念词汇在本文中都有提到（e.g.Stakeholder、Concern、View、Viewpoint），有兴趣的同学可以进一步研究下。
如果你从头到尾耐着性子看到了这里，那么不用怀疑，你一定就是我们团队要找的那种能成大事儿的人：