《架构师修炼之道》摘录10-展示设计决策

本系列内容来自《架构师修炼之道》。在自己的笔记中以半摘录的方式，用 blockquote 穿插自己的思考和感悟，以加深对内容的理解和消化。

全书整体分为三个部分

前两部分适合从头到尾通读，第三部分用于参考和检索。

分享设计想法的最佳方式是把它展示出来。光凭嘴说，别人可能很难理解你的思路。把架构画出来，大家就能按照自己的节奏和方式来琢磨。开发人员都清楚，讨论抽象最好的方式就是找一块白板，画点草图。

架构图没有必要画得很精致，只要能够有效表达想法就行。本章学习绘制架构图，以便开发人员沟通。

10.1 用不同的视图展现架构

一张图画出架构的所有细节是不可能的，需要创建多个架构图视图。视图要么代表了利益相关方的视角，要么解决了一组问题。不同的架构视图可以回答不同的问题。开发进展如何？谁负责开发这些组件？如何支持质量属性场景？

软件系统各不相同，因此没有固定的视图组合。不过有几个视图对大多数软件系统都适用。

线条和方框是架构师最常画的东西。虽然线框图可以表现元素之间的复杂关系，但其架构意义却不是那么显而易见。回忆一下这一张图

这张图还缺少了元素的功能信息。根据要分享的信息，你可以选择用注释、表格、描述性文字来说明元素的功能。

精细视图增加了模型细节，可以不断放大，显示元素的内部运行情况。精细视图聚焦于局部。在逐步放大的过程中，我们既能看清全局，也能掌握关键的细节。精细视图要画到什么程度，可以参考“推出决策”原则。当需要展示特定的质量属性，或者降低高优先级风险时，才有必要将视图进一步细化。

质量属性视图展示了架构如何提升特定的质量属性。它还可以隐藏某些与当前问题无关的细节。

比如要保证可以性，业务组件需要多个实例，在图中可以使用多个图形来表示多实例。比如要解决并发请求的性能瓶颈，架构需要负载均衡器。负载均衡器也需要在图中展示。

如果一张图不足以解释架构如何保证可用性，可以用文字进一步补充细节。就像元素功能视图中提到的一样。

随着视图越来越多，不同视图中元素的关联和关系变得越来越难看清。映射视图可以解决这个问题。它把两个或两个以上的视图组合到一个新的视图里，以便展示元素之间的关系。

前面介绍的视图都比较精确，但是精确的模型需要细节支撑，制作起来非常耗时。有时甚至会妨碍沟通。刚开始接触系统时，使用粗略的模型也许更加有效。

架构草图是一种可以快速绘制但不精确的模型。使用简单的符号，省略了精细视图的许多细节。草图适合用来构思设计。等架构稳定后，再创建更精确的模型不迟。

绘制架构图是为了与利益相关方进行有效的沟通。要是能满足这个目标，采用什么样的形式都行。

视图总是某种“成分“的组合：元素与功能，质量属性与模式，元素与项目进度等。绘制新视图非常简单，只要将新”成分“与架构元素组合在一起就行。如果你想展示系统的性能瓶颈，可以先用组件图画出系统的信息流，然后按执行顺序给组件涂上各种颜色，一张性能视图就画好了。

出色的图表可以降低大家理解架构的难度。下面是一些技巧：

建议

避免

图例对视图采用的元模型进行了说明。添加图例可以让图表保持前后一致，提高其可读性与实用性。无论你采用什么符号，图表都应该有图例。

通过移动元模型的位置，重点突出架构模式。

每一笔每一画都要有所指。颜色、形状、方向、字体、位置的选择都要代表某种含义。添加不必要的细节和装置指挥增加他人理解的难度。选择多种颜色和形状应该时为了突出想法，而不是为了画蛇添足。

注意图表的一致性，如果某个元模型概念出现在两张图中，最好用相同的形状和颜色来表示。如果你不想可以表现什么，就不要随便改变颜色和字体。

细节太多容易产生混淆。不同形状的箭头应该代表不同的含义，否则混用各种形状的箭头只会叫人犯晕。在清晰表达设计思路的前提下应力争保持简洁。

用来描述图片的文字往往是视图中最有趣的部分。这些文字既可以解释视图中的元素时如何组织在一起提升或抑制质量属性的，也可以说明为什么要用这种方式设计系统。有时候，图表反而是视图中最无趣的部分，因为精华都在这些文字里。

描述性的文字讲述了架构的故事，它的形式多样，可以是一小段文字，或者几条要点。视图上加上借助文字和图表共同来讲述架构故事的：架构从哪里来、它怎么工作、它的目标时什么。

找出你最近参与项目的架构视图。试着分析这些图表还能做哪些改进？考虑一下事情：

本章主要学习了如何用图表来展示架构设计决策。介绍了几种常见的视图及绘制高质量图表的技巧。