回到主题，如果上边的问题说清楚了，接下来的事情就相对简单了。对于架构图是什么这个问题，我们可以把之前的等式进行延展：架构图 = 架构的表达 = 架构在不同抽象角度和不同抽象层次的表达，这是一个自然而然的过程。不是先有图再有业务流程、系统设计和领域模型等，而是相反，用图来表达抽象的思考和内容。
那么架构图有什么用？给谁看？回答这个问题需要讲清楚为什么要画架构图，同时也需要考虑一个问题就是：架构图是不是越多越好，越详细越好？
画架构图是为了什么？
A picture is worth a thousand words (一图胜千言)，从 Why 层面讲，我觉得就是如下两点：
- 解决沟通障碍：达成共识、减少歧义。
- 提升协作效率：团队内部和团队之间的协作、沟通、愿景和指导。
但是上述两点其实是非常笼统的信息，如果放在 What 层面，我们必须要考虑架构图面对的“客户”，不同的客户有不同的诉求（其实也就是角度和层次），在不同的抽象层次架构图所表达的信息内容可以完全不一样。以目前团队做的事情为例，架构图的目标客户至少有几类：
- 参与项目的各团队各角色（业务、产品、开发、测试、安全、GOC）
- 项目之外的客户（外部客户，外部评审专家）
- 各层次 TL（汇报，跨 BU，跨团队协作沟通）
所以画架构图，我们必须首先明确沟通交流的目的和面向的客户，只有明确了这两个点，才能更加有针对性地达成上边所说的那两点目标：解决沟通障碍，提升协作效率。
怎么画？
1、先说分类
架构图分类，本质上是从不同的视角，不同的抽象角度去看，作出清晰、简化的描述，涵盖特点方面忽略无关方面。
从业务应用开发的维度，一般的抽象层次可以分为：
业务全域—>子域—>模块—>子模块—>包—>类—>方法
这其中：
- 较低层次的抽象：应用内部包图、类图；某个领域：实体图、时序图、状态图、用例图等等。
- 较高层次的抽象：具有一定的复杂性，比如微服务架构，系统间的交互图，领域/子领域架构图，整个系统架构图等等。
当然，还有很多其他的分类方式，比如：RUP 4+1，GOGAF9 等等分类方式。单从实践的角度，我觉得何种分类不是最重要的，最重要的是想清楚面向谁和解决什么诉求，然后思考架构图到底从哪个角度、哪个层次去抽象。我们目前所做的项目，有很多时候要去和国外的业务专家、技术专家沟通，大家也并没有一个明确的标准定义，表述清楚问题，达成共识是最最关键的，至于架构图的粒度、类别、内容可以逐步地迭代优化。
2、再说构图
构图的部分，我们大家都用 UML 画过类图，涉及泛化、聚合、组合、依赖等等关系，分别用不同的虚实线、箭头样式进行表达。所以画架构图需要考虑架构图的组成元素，要保证符合一贯理解，架构图的组成元素可能涉及：
- 方框、各种形状、虚实线、箭头、颜色（不同颜色代表什么意思）和文字内容
- 虚实线表达什么？组件类型，模块类型，层，服务，需要考虑是否已经实现等？不同状态的标识怎么传递？
- 箭头表达什么?数据流或关联关系？
- 交互类型可以是同步或异步的；关联类型可以是指依赖、继承、实现
构图最最重要的是需要考虑内容术语一致性问题、碎片化问题、信息粒度大小的问题，以及图表的外观问题。
如何评判架构图的好坏
架构图的好坏，我理解主要是两个方向，一个是需要跳出图本身去看，业务领域的抽象设计合理性，是否符合“高内聚，低耦合”的要求，这个需要回到前文的业务建模、系统建模和抽象过程去寻找答案。另外一个方向是图本身，以下几个点供参考：
- 内容术语一致、信息粒度大小一致，图例清晰，颜色类型统一，美观；
- 图中的信息与相应的抽象级别相关，且满足利益相关者(合作方)的需求；
- 一张好的架构图不需要多余的文字解释。受众有没有准确接收到想传递的信息；如果它所导致的疑问比它能解释的问题还要多，那么它就不是一张好的架构图；
- 架构图应该帮助每个人看到大局，了解周围的环境，适当的上下文信息；
- 架构图应该避免“只见树木不见森林”。
最后也聊聊架构师
这是来自于阿白老师的文章《架构师到底是做什么的？》，越是琢磨，越觉得深以为然。其中提到了好的架构师的画像和不好的画像，如下图，与大家共勉。
从我个人的成长经历看，架构师很重要的一点要学会“权衡”，既要兼顾当下痛点也要符合未来一定时间的发展，既要保留未来的可扩展性也要避免过度设计。选择什么样的时间节点、什么样的业务场景以及什么样的架构迭代策略至关重要，这些决策的关键在于判断和取舍，需要结合深刻的业务思考乃至组织架构去做权衡落地。和大家分享一点点不算经验的经验：
快速学习
快不是一个速度问题，也是一个判断或者标准问题。面对一个全新业务场景，如何能够识别20%的关键业务路径、关键业务痛点，如何短时间把自己变成业务专家，这是一个架构师基本的素质。我的经验就是要去「吸金式」的思考，带着问题主动思考，客户是谁？有什么诉求？需要解决什么样的问题？我们能提供什么样的价值？多问为什么？这也需要长时间的刻意训练。
不要屁股决定脑袋
要跨角色、跨层级去看待业务问题，这个点容易陷入说教，说实话我自己做得也未必到位。但是时刻提醒自己的思考是否被局限，在哪一个维度，是 Have-do-be，还是 be-do-Have ，同时要一直提醒自己不要屁股决定脑袋。
提升思考能力和对于技术原理或本质的理解
我觉得这是最底层的能力，业务开发中我觉得最大的两个难点：一是逻辑的复杂性，二是需求的变化性。我们不应该把大部分时间花在寻找解决方案上，而应该花更多的时间在选择解决方案上。这就要求我们对业务全局、行业深度、技术视野、技术深度、业务共性、个性特征等等形成自己的认知。权衡取舍，取什么舍什么？该怎么取怎么舍？那个度在哪里？唯有思考，自驱，累积和坚持，勇猛精进，志愿无倦。
最后的最后
希望这篇文章对大家有帮助，附上最初在考虑这个主题时的构思过程及思考路径，供大家参考。
