架构制图：工具与方法论

本文插图
前言
“架构制图”这词乍一听似乎有些晦涩，但如果提起“工程制图” ，相信绝大部分工科背景的程序员们都不会陌生，甚至还能共同感慨下那些年一起伏在宿舍左手圆规，右手直尺，徒手作图到深夜的日子。
软件工程也是工程，因此传统工程制图的一些基本理论，在软件行业同样适用。但另一方面，软件与实体制造业之间还是有着本质区别，所以在制图方面的需求和方式也大相径庭，无法直接套用。作为软件行业的从业者，你可以完全不懂工程制图，但你不得不懂架构制图 —— 这是任何程序员职业生涯的的必修课。
本文在后半段将介绍如何用图去描述（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），才让成百上千工人们的分工合作和验收标准有了依据：大家只需要照着蓝图，按部就班地把自己所负责的那些砖瓦添上去就行了；只要蓝图正确，且施工过程也没有偏差，最终顺利完工只是个时间问题。