架构师修炼之道

比如客户要求软件具备高可用性，能够相应99.9%的请求，我们可以引入冗余元素来提高可用性，但是必须采购双倍的硬件，从而成本也翻倍了。这样做就是用更高的成本换取高可用性

架构师知道系统是如何分解的，他们关注大局，指导划分出来的各个模块协调工作，还要将业务需求与技术决策放在一起考虑。

只有这样，架构师才能游刃有余的管理技术债务

技术债务的多少可以通过填平鸿沟所需的代价衡量

技术债务就像是软件系统的副产品

它可能对软件的质量属性、开发进度、成本产生影响，有些影响甚至无可挽回

一项重大决策可能会影响到很多人，甚至让其他软件系统不得不做出改变

重大的设计决策一旦出错，后续修改将付出巨大代价

设计得当的架构能提升利益相关方需要的质量属性，抑制或消除利益相关方不需要的质量属性

架构也可以提升其他软件特性

这个结构定义了软件系统的组织与协调方式

它提现在你编写的代码和运行的软件中，甚至体现在你与他人的协作中

将两个元素以某种关系连接在一起，就成为了结构

元素是软件的节本组成部分，关系则描述了元素如何协作完成任务

将相同类型的元素和关系连接在一起，就形成了结构

用模块结构考虑可测试性和可维护性

用组件连接器结构考虑运行时的问题，如可用性和性能

包括可伸缩性，可用性，可维护性，可测试性等

与软件交互时，用户就能体验到质量属性

思考架构设计可以确保你设计的软件系统能够支持你关心的质量属性

随着架构职责的增加，你会发现编程的时间越来越少

利益相关方是谁，主要业务目标是什么？

项目的整体解决方案是什么样的？

涉及哪些技术？

最大的风险是什么？你是如何克服的？

如果有机会重新做一遍项目，你会如何改进？

就算你是程序员，每天也会做出数十个设计决定，这其中有些决定就是具有架构意义的

任何人，一旦做出了影响软件结构的决定，实际上都充当了临时架构师

“重要的设计决策（其重要性由变更的成本来衡量）

水无定形，若软件如水，则架构如器。容器既可以是坚硬的铁桶，也可以是轻巧的塑料袋，它可以很厚重，也可以很轻薄。如果没有架构，软件就像流浪的水一样无法控制

这些原则不仅适用于软件架构设计，也适用于程序设计，交互设计以及所有设计工作

四条设计原则

我们使用这四个英文单词的首字母（HART）来记忆这些原则

《Less is More with Minimalist Architecture》中建议设计极简主义架构

极简主义架构只关心高优先级的质量属性，只考虑如何在提升这些质量属性的同时尽量降低风险，除此之外的其他设计决策都可以悬置，等时机成熟后再做决定

极简主义架构要求我们尽可能推迟那种一旦决定就难以改变的设计决策

呈现架构的方式很多，可以画出来，可以制作原型或简单模型，可以演示部分系统的控制流程，甚至还可以打比方。这些方式能从不同的角度展示软件的结构和质量属性，方便他人理解架构设计

人们只有通过感性的认识才能理解和消化架构。分享架构的唯一方式是把它具体的呈现出来

设计架构时，我们先选择一种思维模式，再运用配套的方法发现架构，然后不断重复这个过程

理解对方的需求其实就是站在对方的角度考虑问题

为了理解问题，我们必须了解所有与系统有关的人以及他们需要什么。

头脑风暴只是探索想法的一种手段

为了找到最佳组合，需要研究大量的模式、技术、开发方法。

我们既可以评估全部架构，也可以评估部分架构，还可以只评估某个模型、概念、想法。

最常用的评估方法是针对不同的场景审视某一块架构，还可以通过实验，或者通过检查决策风险来开展评估

评估还可以用来检查任何工作成果，判断它们是够满足我们的需求。

这个方法分三步：思考（Think）、动手（Do）、检查（Check），我们称为TDC循环

每一次循环迭代都针对一种特定的思维模式展开

思考

动手

检查

由于软件没有止境，因此这个循环流程也就没有终止条件。无论是改进现有设计，还是创造新的架构，都可以用到这里介绍的流程。

理解用于获取利益相关方的诉求，并将这些诉求转化成清晰的产品需求。

探索着眼于寻找各种解决问题的模式、技术、方案。

展示对系统进行建模，以便我们有具体的对象进行推演和分享。

评估则对模型和需求进行验证

在工作中，我们需要频繁快速的切换思维模式。比如一次对话中就可能多次改变思维模式

思考

行动

检查

思考

行动

检查

思考

行动

检查

架构师不是无所不知的技术先知。

应该把每个可能的解决方案都堪称待验证的实验。

验证的速度和效率越高，找到合适的组合结构的时间就越短，利益相关方就能越快受益。

架构是软件系统的基础。

如果架构出错，那一切都完了。

架构师必须时刻考虑哪些地方可能出错，并据此开展设计。

根据风险决定接下来设计什么

简单的问题通常也有简单的解法。

简化问题的方法很多

我们学习的越快，就探索的越多，对解决方案也就越有信心。

如果有可能失败，越早知道越好

设计周期太长往往是因为目标过于宏伟抽象，相比之下，我们更喜欢能产生具体成果的频繁迭代设计

在《Notes on the Synthesis of Form》一书中，作者展示了如何一边考虑解法，一边定义问题。

问题的边界是由可能的解法勾勒的。

设计软件架构需要我们同时考虑问题及其解决方案

如果前期不涉及架构，那么开发出来的系统很可能不符合要求

用适当的时间设计架构能降低未来返工的风险

不过如果前期在架构设计上花的时间太长也会耽搁开发，延误交付

返工包括弥补设计缺陷、重写代码、改正错误等

要找到最佳平衡点，必须整体考虑设计成本，以及为了完成系统不可避免的返工

随着架构规划时间的增加，返工量会逐步减少

实线是架构设计时间和返工时间之和

这些数据可以用来评估你的架构设计时间是否在合理范围内

可以通过系统规模来估计

可以通过系统复杂度来预估

对于可以用常规解决方案处理的系统，即使规模很大也可以不做太多的前期架构规划

还必须要考虑需求波动

我们常说的“万一。。。”则属于猜测

条件是当前的实际情况

后果是由条件引发的、将来可能出现的不良状况

模型训练服务最初是为其他目的开发的；新请求可能会导致其过载

数据处理将消耗大量的时间和资源：可能无法顺利完成处理任务

需要大量数据训练统计模型：数据的存储成本搞，模型可能无法盈利

存储的数据可能包含敏感的客户信息：对数据进行隔离的要求超出了我们的能力范围

在面对必须降低的风险时，首先确定可以解决的部分：风险的条件、影响、概率、时间、窗口。然后选择一种设计模式

可以帮助你选择合适的思维模式

别忘了借助第二章介绍的TDC循环，考虑风险并决定下一步该做什么

主动设计是指主动设法降低架构风险

被动设计是指监控系统运行表现，只在必要时采取纠正措施。

进一步修改和完善文档

根据出现的新情况对架构进行微调

通过结对编程和代码评审来培训团队成员

我们还要继续与架构变异（参见第12章）和其他问题作斗争

可能是由于新的风险出现了

系统的实现偏离了计划

也许会发现先前的假设是错误的

实际环境发生了变化

要花多少时间做前期分析？

预计需求是否会出现变化？

何时开始编写代码？

无论需要多长时间，只要你记住第2章介绍的设计思维的四条原则，专心寻找够用的设计，那么应该能在需要时间里找到一个可行的解决方案

是限定前期设计的时间，还是无论花多长时间都会不断通过设计来降低风险？

是在开始写代码前做尽量少的前期设计，还是尽可能地完整地做好架构规划？

各个部分的实施可以独立开展么，还是某些部分需要一起开始？

上述问题都没有标准答案，结束条件在很大程度上取决于团队、利益相关方、项目背景的实际情况

在开始之前，告诉大家你准备如何记录设计架构

给出关键设计工作的时间节点

你至少应该给出对结构设计有重大影响的事件（需求审查、设计审查、需求评估等）的时间节点

还要给出与利益相关方会面的时间节点

我们使用的是风险驱动的设计方法，因此应该将重大风险也放到设计计划里

在软件系统的整个生命周期中（尤其是在做前期架构设计时），你应该不断回顾风险列表

可以先从可行的解决方案里选一个

思考解决方案可以更好的帮我们定义问题

概念架构不需要很复杂，你可以画一张草图，只要能表达初步的设计想法就行

它将人与人之间的关系和互动进行可视化的呈现

这张图还能大致展示不同利益相关方的动机

你可以用它确定需要沟通的关键人物

先搞清楚谁是客户，他们想做什么

然后将系统按照客户的任务进行划分

具体步骤

业务目标是利益相关方希望通过软件实现的东西

谈论系统的质量属性、权衡取舍、技术债务都要以业务目标为基础

当多个需求发生冲突时，可以根据业务目标对它们进行优先级排序

主体

结果

背景

例子

更多的目标将难以理解和记忆

与多个利益相关方合作时，一定要标注目标的相对重要性

比如观点填空图

其他业务目标模板将在第14.8节中详细介绍

这些人通常可以毫不费力的描述系统的业务目标

如果他们也不能清楚地描述业务目标，你们应该一起搞清楚，因为他们也要对项目负责

约束

质量属性

影响较大的功能需求

其他影响因素

业务约束限制了对人员、流程、成本的选择

技术约束则限制了对可用技术的选择

例如

必须这么做，否则项目就会失败

尽量这么做，除非有合适的理由

随着系统主键形成，设计决策有可能变得越来越像约束

系统不再简洁、敏捷、有延展性

早期的设计决策有可能成了设计师的枷锁，让修改架构变得极其困难

因为架构师有权选择更改束手束脚的设计决策

大多数设计决策在提升某些质量属性的同时抑制了其他的质量属性

牺牲某个质量属性换取另一个质量属性，架构的结构选择就是这样逐步实现的

软件工程教科书通常会讨论两类需求

质量属性仅在系统运行时才有意义

例如约束没有谈判余地，而质量属性则可以取舍

也就是说系统除了能够正确响应，如何响应也很重要

NASA喷气推进实验室火星探测机器人可移植性场景

Lionheart项目的质量属性场景

在项目初期，架构可能只存在于纸面上，但可运行的系统迟早会出现

如果你不知道如何对场景进行测试，那么这个场景实际上就缺少具体、可衡量的响应度量

反例

1. 先画出概念架构草图，展示你当前对架构的构想

2. 对功能需求进行大致分类，每类需求反映一个相同类型的架构问题

3. 对照概念架构草图，思考每个分类如何实现。如果对于已知的粗粒度需求，实现功能的方式并不明显，那么它就可能对架构有重大影响

影响架构的因素

如果你手里只有锤子，那你看什么都像钉子

新硬件、新软件、新设计范式不断涌现，有些将对软件开发软件产生深远的影响，有些不过是“旧瓶装新酒”。

该定律1967年由Melvin Conway踢出，后因《人月神话》的引用而广为人知：“任何设计系统的组织......产生的设计必然是该组织沟通结构的写照”

同一个组件，三个不同的团队会开发出三种不同的版本。架构中各种元素的边界正是人们沟通边界的投影。

架构中的通信路径反过来也会影响团队的组织结构。

如果你想设计最好的软件，那么你必须准备好重新组织团队

将业务目标、质量属性响应度量与具体数据要求联系起来

搞清楚质量属性场景和约束，这对技术利益相关方尤其有效

将隐藏需求明晰、公开化

快速有效地定义高优先级的质量属性场景，这对任何类型的项目，以及有不同技能和背景的利益相关方都奏效

启动一个新项目时，将启动计划书(inception deck)作为检查清单。架构设计是其中的主要内容

你再在做手机需求的计划是，可以把这个大纲作为检查清单

A向B讲一个故事，可以是A的一项成就或解决的一个问题。请注意，在A讲完之前，B一句话也不许说。A讲完之后，B才可以提问，以便进一步理解A讲的内容。B的提问不能包含反馈和评价，提问的目的是理解A的话。接下来双方互换角色再进行练习

人类语言模糊而复杂，又受不同文化的影响，而且文化不仅与国家和宗教有关，不同的城市、公司、学校、俱乐部都有自己的文化，都会影响人们的沟通方式

请保持安静，不要做批判，踢出问题，尝试理解

如果没得选，那就不需要决策了

设计探索是反复地发散和聚合的过程

备选方案越多，我们决策的信心就越大

由于时间有限，架构师只能重点关注质量属性、架构结构，以及会对这两者产生影响的设计决策

软件架构是关于如何组织软件的一系列重大设计决策的集合，旨在实现期望的质量属性和其他软件特性

探索元素及其作用，确定架构的结构组成

探索关系及其结构，确定元素的交互方式

探索问题领域，理解架构所处的环境

探索技术和框架，提升质量属性

探索构建和部署方法，确保架构可以交付

探索以往的设计，获得启发，指导决策

面对技术约束，我们别无选择

业务约束则较为微妙

多年前，我所在的公司被一家规模更大的公司收购。新公司的法务团队制定了新政策，要求不再使用在某些许可下发布的开源软软件。这条新政策(约束)给我们额外增加了近一年的开发任务。

我们得到的教训是：利益相关方并不一定理解约束对架构的影响

展示了三种搅拌机，都具有独特的质量属性

表6.1三种搅拌机的主要质量属性对比

决策矩阵

表6.3

看看表6.3，你会选择哪种模式？是否还有其他因素可能影响你的最终决策？

决策矩阵可以用来总结探索结果，还能用来与利益相关方就设计决策的取舍进行有效的讨论（记得向对方解释矩阵中的记号及含义）

表6.4 Lionheart项目元素的功能

不做决策是否阻碍了项目进展？

决策能否解决不能再耽搁的问题？

决策是否会创造更多选项或机会？

推迟决策是否明显会带来的一切后果？

我是否理解并接受决策带来的一切后果？

我有明确的理由说明为什么现在必须做这个决定吗？

如果决策失误，是否有时间弥补？我能承受这样的错误吗？

不过还好，如果出现这种情况，还有一个窍门可以避免情况恶化：可以把那些容易变化的东西移出架构

SOLID代表5个面向对象设计原则

例如：如果性能是头号质量属性，那么选择SOA很可能就不合适。

选择错误的架构模式会严重妨碍提升既定质量属性。

例如：如果架构设计用了发布订阅模式，那么使用关系型数据库作为消息传递的主要机制就不合适，它会影响发布订阅模式希望提升的质量属性。

为避免架构失配，一定要选择与架构设计相匹配的技术。

设计模式是所有设计师必须掌握的。除了编程、软件架构设计、企业架构设计之外，用户体验、测试、数据库，甚至开发流程都有线程的设计模式。设计模式在现在软件开发中有着重要的地位

设计模式就像《设计模式：可复用面向对象软件基础》中列举的那些模式。这类设计模式可以提高面向对象程序的可复用性和可维护性。

架构模式定义了各种质量属性场景（包括设计属性、运行属性、感知属性，详见地5.2节）的解决方案，常常涉及软件系统的多个组件。

架构模式关注的质量属性与抽象粒度都更宽泛

Unix的终端命令可以连接在一起，它运用的就是管道过滤器模式

传统的SOA非常倚重消息总线和SOAP通信

现代SOA则鼓励使用细粒度的微服务，用轻量级的消息协议（如HTTP）进行连接

大量的消费者订阅各种生产者发布的事件。生产者和消费者通过事件总线间接通信，事件总线负责将发布的事件与感兴趣的订阅者连接起来

事件总线技术的选择极大地影响系统属性

毫无章法的开发和缺乏架构知识是导致“大泥球”出现的主要原因。

以问题为中心的方法是从一个常见的问题入手。如果你反复看到同样的问题出现，你可以试着开发一个通用的解决方案。研究现有的解决方案模，找出其中的相同之处与不同之处，根据你的分析，尝试描述新解决方案模式

以解决方案为中心的方法则是从反复使用的解决方案入手。也许其他开发人员还没意识到这一点。描述你观察到的解决方案模式，分析它能解决那些常见的问题，试着把它定义清楚。

模型来自我们对世界的认知以及我们为表达设计意图所做的努力

所有模型都有概念，规则描述了概念的使用方式。正确运用这些规则，才能让模型与我们的认知保持一致

字词传神，至关重要。

在软件开发中，细节决定一切

模型可以帮助大家思考和描述系统行为

所有开发人员都应该理解为什么选择当前的设计

在设计阶段修改架构缺陷要比开发、测试、验收、发布后再修改容易的多

在白板上发现、修复问题要比在说千行代码里做快得多

在探索架构时还需要做试验和创建原型，借助模型思考不能代替动手实践，不能只用图标和框图来分析预测系统的行为，所以应该今早写代码开始验证

元模型就好比是设计的语法，它规范思考方式，并且设定了讨论架构的词汇

元模型的作用

当你蹒跚学步时，你第一次见到门。观察大人开门后，你猜测转动把手可以把门打开。这时你就将门与墙的概念分离开了。有一天你试着转动把手开门，结果门却纹丝不动。于是你又将上锁的门与没上锁的门的概念分离开了。你的思维模型就是这样逐步建立起来的

适用于建立任何模型，无论是现实世界的模型，还是软件系统架构

这个循环总是从提问开始，提问是检验的手段。检验的结果要么是在模型中找到了答案，要么是发现认知还存在偏差。如果找到了答案，就强化了现有的模型。如果发现有偏差，就要修正模型（分离概念）

好奇心循环的例子

从提问到解决会花一些时间，而且这里也有风险，比如我们的知识和经验不足以分离新概念，也就无法正确的设计系统。为了降低这种风险，我们可以选用现成的元模型（如架构模式）

比如两个模型都有worker元素，但是职责和使用规则又完全不同

为了保持一致性，应该对相似的概念进行合并，对同名不同义的概念进行更名，对使用规则做出相应调整

规则描述了元素和关系在系统中的交互方式，它们必须反应实际情况

规则还描述了我们在架构上引入的概念约束（conceptual constraint）

建立规则的方式与建立其他概念的方式相同。先提问，然后检验模型，再通过修改或添加规则更新模型。如此循环，直到模型能解决问题

七个阶段如下

表8.1是一个元素名称演变的例子

比如使用的是分层模式，那么就应该称代码包为层

比如使用了管道过滤器模式，那么就应该用管道和过滤器给类命名

按照领域概念进行建模和编码，是面向对象变成的常见做法

展示了一个合理地分层组织代码包的例子

组织代码的方式不止一种，比如还可以按照功能模块来组织代码

我们至少应该做到将代码组织到包里，使之与架构元素对应

仅靠纪律和警惕性维护架构的完整性是不够的

模块结构在代码中最容易看到，但通常最难贯彻落实。

贯彻落实组件连接器模型的一种方法是将系统设计为在违反架构约定时就终止运行

贯彻落实组件连接器模型的另一种方法是防止不应连接的组件之间的连接

微服务架构的迅速普及多少是因为它使领域模型在运行时可见且可落实。

在代码中表达分配模型背后的意图曾经是一个难题。由于平台即服务（platform as a service, PaaS）、容器技术（如docker）、基础设施即代码（infrastructure as code，IaC）和分布式版本控制系统等技术的出现，现在有可能在代码中描述和贯彻落实分配模型了

将代码视为基础设计，为静态分析创造了机会

容器是轻量级的、可丢弃的

分布式版本控制与基于Web的工具（如GitHub）相结合，可以轻松地将特定的架构组件分配给某个团队开发

最好能简要解释错误背后的设计原理，避免采用一般性的错误描述

大多数编程语言都有依赖分析工具，使用这些工具生成的模型可以分析模块结构

要生成组件连接器结构必须添加分析工具以便观察运行时模型

为了让大家在短时间内尽可能多地提出想法，你必须对设计研讨会的探索活动设计严格的时间限制，同时指导团队”先发散后聚合“——首先发散探索，然后快速聚合想法

为了提高会议质量，让与会者积极参与并认可设计决策，应该做到设计探索的三个F——快速（fast）、有效（effective），有趣（fun）。有趣才能提高参与度，而参与度又进一步提高会议的速度和有效性

可实现的想法

有待评估的想法

引发新问题的想法

无论时间长短，研讨会的基本流程都是相同的

开会前你至少应该了解了大致的业务 目标和关键架构需求。

你要与利益相关方沟通、做基本调研、设法确定业务目标、提炼质量属性和关键架构需求（ASR）

你应该充分了解问题及其背景，以便有效阐述研讨目标

准备研讨会可能要几天甚至几周时间

避免开会时有人在讨论数据库设计，而有的人在讨论死锁问题

清楚阐述研讨目标有助于提高大家的参与度

你应该向大家分享目前你对问题和架构的认识，确保每个人都正确了解问题背景，然后回顾研讨会要探索的内容

具体花多少时间分享背景信息要根据大家所了解的情况来定。如果有不少人是第一次接触业务目标和关键架构需求，那就应该多花一些时间做介绍

明确的目标有助于大家在整个研讨会期间集中注意力。

会议期间，每个人都要针对目标踢出备选设计方案。

大家还将根据目标评判这些设计方案。

在这个阶段，我们更重视想法，而不求形式上的完美

参与者针对研讨目标，独立或以小组的形式提出设计想法（画图或建模）。用纸和笔把想法画出来是比较合适的做法，不必追求精确。

这一步应该限制时间，通常是5到7分钟，时间宽裕的话可以相应延长

创建完成后进行分享，这一步也叫游说（pitch）

每个小组有三五分钟分享创建的内容，解释自己的设计如何满足目标。

分享应该做到简明扼要，不需要全面展开。

分享时，其他人只能听，不允许提问。进入评判阶段后，每个人都有机会提问和给出意见

一个小组分享完后，其他人开始评判

评判应该围绕设计与目标的关系展开

评判过程中，每个人都要就事论事，实事求是

所有小组都分享完后，开始新一轮迭代

创建阶段构思和绘制设计；分享阶段展示设计方案；评判阶段指出忙点，督促大家改进，或者尝试其他方案

在不影响研讨质量的前提下，迭代速度越快越好

如果有些人是单独一组，可以让他们结对或组成小组。

如果大家已经组成小组，可以将这些小组重新混编

趁着大家记忆犹新，赶紧做好笔记

尤其重要的是记录下一步的行动要点及行动负责人，以确保按计划开展后续工作

除了轮转设计，你还可以尝试白板涂鸦（详见第15.9节）。

如果想找到合适的系统隐喻，可以选择架构拟人化（详见第15.1节）

总之，应该挑选有助于实现研讨目标的设计方法

与会者太多会增加会议成本

不合适的参与者会妨碍建设性的讨论

小组人数超过七人，就难以有效开展协作

一个主持人一次最多也只能应付三四个小组

三五个人的小组，通常是讨论架构设计的最佳人数

挑选那些善于提问和思考复杂问题的人

确保与会者拥有不同领域的经验

每个参与者都具有独特的视角，就能更深入和广泛的开展研讨，避免出现众口一词的情况

团体迷思

团体迷思将导致集体决策不是最优解，甚至是有害的

团队表现及含义

比如鼓励那些沉默不语、随波逐流的人多发言

缺少分歧的讨论看起来很和谐，效果却正相反

冲突和辩论才能让我们免于故步自封，让新鲜的想法脱颖而出

比如让团队对大体方案达成共识，为进一步完善细节打下基础

如果大家不能很好的理解问题，那就需要在几周内举行多次小型会议

并非所有问题都适合在研讨会上探索

会前介绍研讨目标有助于大家快速进入状态

议程没必要讲的太细致，有些细节还应该保密，一面参与者产生困惑或做出先入为主的设计

如果会议时间长达几小时，至少应该宣布每个议程的开始结束时间，以便参与者可以选择是否参加某项活动

人人参与

时间一到，马上进入下一个环节

回答不分对错

遇到不明白的地方，请提问

注意时间

展示例子后再回顾之前的说明，让参与者有第二次机会就不明白的地方提问

简单的提醒和建议可以起到很好的作用

留意那些神情木讷的人，他们可能需要帮助才能进入角色

最基本的条件，比如屏幕共享，协作绘图，群聊，语音通话等

远程研讨会需要更多时间完成协作和设计活动，会议中往往还会出现技术问题，你需要提前做好准备，才不会手足无措

电话里一次只有一个人可以说话，在这种情况下，小组协作会非常困难，应该用群聊软件作为备用沟通手段

如果需要小组协作，给每个小组设好电话会议号，并且预定截止时间，以便他们能及时回到大组讨论中来

参加远程会议的人很难集中注意力

你应该提前准备好演示材料，这样外地参与者可以在自己电脑上打开观看

讨论时，大家可以共享一个文档，所有人在共享文档上编辑、修改内容，这样每个人都能参与进来

没有什么方式比面对面互动更有效。如果有可能，最好用视频会议软件，让参与者至少可以时不时看到彼此

研讨会不是探索想法的唯一方式

你可以在持续的几天时间内，以一种更慢的节奏开展很多设计活动

放大地图，可以看清城市的条条大道。缩小地图，城市就变成了洲际高速沿线的小点，打开叠加层，可以看到实时路况和天气。我们还可以在街道地图，卫星地图，地形图之间切换。用些应用还提供街景，让我们看得更清楚

开发进展如何？谁负责开发这些组件？如何支持质量属性场景？

虽然线框图可以表现元素之间的复杂关系，但其架构意义却不是那么显而易见

元素功能视图很常用，有些项目只需要这一个视图就够了。只要列出元素及其功能，就有可能开发出可用的系统

精细视图聚焦于局部。在逐步放大的过程中，我们既能看清全局，又能掌握关键细节。

精细视图要画到什么程度，可以参考第2.1节介绍的推迟决策原则，只有需要展示特定的质量属性，或者降低高优先级风险时，才有必要将视图进一步细化

图10.2 Lionheart项目展现业务组件放大图

经过一层放大后，我们可以看到展现业务组件使用了典型的分层模式：展示、业务和服务访问逻辑层，外加用了组织数据模型和使用程序列的“挎斗”层

图10.2展示了该组件采用的模式，如果想了解更多细节，还需要进一步放大

为了满足这一质量需求，我们引入了冗余模式

工作分配视图在团队及其开发的元素之间建立映射关系

部署视图显示组件连接器视图中的运行时元素的安装和使用位置

例如，考虑产品经理的需求，他也许很关系某些功能何时可以交付

架构组件及其功能之间的映射可以展示软件的各个部分对应哪些功能

有了这些信息，团队能够开展自我组织，开发人员就能在了解产品经理需求的情况下调整工作任务的优先级

前面讲的视图都比较精确，但是精确的模型需要细节支撑，只做起来非常耗时。

精确有时甚至会妨碍沟通，尤其是在探索想法时

它非常适合用于临时沟通，但不适合用来做详细分析

架构草图在快速迭代和非正式沟通中很常用，尤其适合在设计研讨会上做临时讨论用

架构草图使用简单的符号，省略了精细视图的许多细节

如果你想展示系统的性能瓶颈，可以先用组件图画出系统信息流，然后按执行顺序给组件涂上各种颜色，一张性能视图就画好了

缺少图例的图

添加图例的图

改变组件的位置

重新排列服务后，不难看出架构使用的是多层模式（见图10.12）

重新排列后，模式变得清晰可见了，其他人将更容易理解架构的设计意图

他建议将系统的逻辑视图和开发视图合并起来，用一组图表反应戴莫内容。

为此他突出了C4模型——一组从不同抽象层次展示系统架构的图标

为避免混淆，他建议尽可能使用简单的，不言自明的符号，并且添加必要的图例

最后，还可以在方框中添加一些描述文字（如模块功能），这样的图标简洁大方、一目了然，还可以减少歧义

添加不必要的细节和装饰只会增加他人理解的难度

选择多种颜色和形状应该是为了突出想法，而不是为了画蛇添足

如果某个元模型概念出现在两张图中，最好用相同的形状和颜色来表示

如果你不想可以表现什么，就不要随便改变颜色和字体

不同形状的箭头应该代表不同的含义，否则混用各种形状的箭头只会叫人犯晕

在清晰表达设计思路的前提下应力争保持简洁

这些文字既可以解释视图中的元素是如何组织在一起提升或抑制质量属性的，也可以说明为什么要用这种方式设计系统

有时候，图标反而是视图中最无趣的部分，因为净化都在这些文字里

开发软件既要与人打交道，也要与技术打交道，两者同样重要

架构描述展示了所有东西是如何组织在一起的，为了管理和协调开发工作，每个人都需要知道系统中的组件如何协同运作

所有利益相关方都有权理解架构

架构模型建立了设计词汇，架构描述则将这些模型转化为利益相关方可以理解的形式

架构描述最重要的作用之一是向业务相关方展示软件架构是如何实现业务目标和提升质量属性的

质量属性通常不那么清晰可见，容易被忽略

架构描述将质量属性视为一等功民，将质量属性清晰呈现出来，化虚为实，让人们可看、可读、可谈

如果不试着写架构描述，很容易就会以为所有东西都清楚了。

笔尖触到纸的那一刻，你会发现脑子里的想法不过是一团浆糊

写架构描述强迫我们搞清楚什么是我们知道的，什么是我们认为我们知道的，还有什么是我们不知道的

我们无法推演看不见、摸不着的东西。我们也不能等到设计决策在代码里实现后再来做评估

架构描述提供了一种分析设计决策的媒介，以便及时发现错误。花一个小屋解释一个愚蠢的想法，总比花一个月开发要好的多

软件架构很酷！你倾尽全力设计的系统，应该让所有人都来欣赏

架构描述是展示系统的有效方式，它能让客户和管理层对你的设计产生信心

架构描述中清晰的目标、计划、愿景将彰显你的领导能力

较小的系统可以采用白板和故事板

如果是为受监管行业开发系统，根据法律要求可能需要用文档记录所有设计决策

设计决策发生变更的可能性大吗？

将来准备在多大程度上分享设计决策？

根据受众的需求定制

用多个视图展示架构

清晰定义元素及其功能

解释设计决策的逻辑依据

故事、隐喻、草图都属于部落描述方法

我们的工作总是从这里开始

这类文档很长，需要更多精力创建

正式模型（用数学模型定义的那种架构）需要更高的准确度和精度

如果系统风险和架构决策风险较高，伙食需要高度协作，可以考虑采用正是描述方法

有些行业可能要求使用正式文档

尽量从白板、草图、系统隐喻开始设计，而不要从传统文档开始设计

在做决策时，一次记录一条架构决策记录。一旦做出决定，将所有内容汇总到架构主旨里，然后继续重构代码，使其正确反应设计模型

架构逐渐定型后，如有必要（或利益相关方有要求）再创建传统的文档

虽然这类文档非常耗时，但它们有重要的价值

大多数利益相关方，甚至是开发人员，可能从未见过整个架构，而SAD可以将所有东西汇总在一起

网上有许多现成的模板

我推荐使用软件工程研究所（Software Engineering Institute，SEI）的超越视图（views and beyond）和ISO/IEC/IEEE 42010标准模板

所有传统架构描述都包含相同的基本部分

在实际工作中，最好不要采用这种描述方法

用精美的幻灯片描述架构，这是一种浪费时间的做法

根据受众的需求定制

用多个视图展示架构

清晰定义元素及其功能

解释设计决策的逻辑依据

谁会读你的架构描述？他们需要什么？如何才能提供他们需要的信息？

之前通过换位思考，我们已经确定了利益相关方的需求。我们设计了架构，用来解决他们的问题，现在要做的是设法分享这些信息。

只有了解受众，才能写好架构描述，你写的越好，人们就越愿意阅读，这又会进一步扩大设计决策的影响

如将代码按层次组织，这样就可以随时放大查看细节，缩小纵观全局

分层有助于清晰思考

充分利用架构模式提供的通用名称，如连接器，层等

分层需要花时间进行调整，才能做到清晰无误

将注意力集中在源代码上是相对容易的，但系统的运行同样值得关注，还有如何将其分配到硬件和容器里。如果你希望清晰的思考，不妨从多个层次讲故事

他们在项目中的角色和职责是什么？他们如何处理信息？他们如何使用你提供的信息？

有时创建受众的移情图（empathy map，详见14.2节）是个不错的方法

请使用受众熟悉的领域语言，提高架构描述的可理解性

尽量使用大白话，避免使用生僻的行话

必要时，可以对架构概念做简单的解释，以确保受众掌握必要的背景知识

沿用利益相关方已经使用的设计术语（除非存在误用）

首先保证有效沟通

不是所有人都了解设计符号的用法，尤其是UML的用法

所有图标都应该附上图例，用图例说明符号的意义和元模型

统一对齐方式，考虑板式在屏幕上显示和打印效果

漂亮的文档能给读者留下好印象，说明内容是由专业人士创建的，值得新来

表11.1总结了编写文档的注意事项

开发人员希望了解代码结构、部署方式、组件交互方式

测试人员希望了解接口和通信协议

产品负责人希望了解技术依赖和整体进度

新成员可能会被文档淹没，需要帮助才能起步

另外，架构描述至少还应包含设计决策、决策依据和架构结构

表11.2是部署视点中的一个视图

部署视点的其他视图将补充组件依赖、第三方软件要求的平台、风险、成本、网络拓扑等信息

我推荐软件工程研究所（Software Engineering Institute，SEI）的超越视图方法、Phillipe Krutchen的4+1视图模型（4+1 View Model）、Rozanksi和Woods的视点与视角（Viewpoints and Perspectives），以及Simon Brown的C4模型

这里有一些例子

比如为了提升某个质量属性选择某种架构模式，或者为了节省成本选择某种技术

比如文字描述或几条要点。有时候列出所有淘汰的方案比冗长的解释更有说服力

有一种描述方式是列出那些被淘汰的方案

列出淘汰方案相当于对决策过程进行回放，以便其他人理解我们是怎么走到这里的。

如果省略这些信息，就如同看电影只看到了最后五分钟——错过了所有的剧情，也就难以理解决策最后的行为

人们可以在眨眼间闪过几十个念头，有些甚至连自己都没有意识到

经团队讨论做出的任何决定都应该正式记录下来。如果你发现自己有强烈的表达愿望，试着将你的想法记录下来，其他人也将从中收益

例如对于需要大量继承或对硬件有较高要求的系统，签字验收可以避免代价高昂的返工

这条原则既适用于代码，也适用于架构，即使在架构设计初期（动手写代码之前），也有指的检验的地方

1. 要有评估对象

2. 要有评估准则

3. 制定计划

人们习惯评估有形的东西，而不是别人脑袋里的想法

用直观的方式呈现架构，可以更好的展示设计思路和设计意图，让大家明白我们准备如何落实关键架构需求（ASR），或者我们已经采用了哪些做法来落实

呈现架构的方式很多

比如

将所有用例按顺序画出来也无法清楚的展示架构

代码评审不能代替架构评估

方框不是唯一的架构元素

在上述的三种问题中，我认为最重要的是理解架构图中连线的作用

一个人眼里的杰作，在另一个人看来也许是糟粕

因此需要建立评估准则，用各种标准判断架构的适用性

指标（criteria）是指待评估的架构属性

评分（rating）是对指标的打分

例子

关键架构需求从利益相关方的角度定义了系统目标

合格的指标应满足以下条件

质量属性场景完全满足这些指标，可以作为评估指标

评估过程中，评估者用统一的评分标准为指标打分。

上面我们展示了评分标准和作用，但是没有解释评估者是怎么打出分数的，用合适的方法引导评估者打分也很重要

评分准则包含要回答的问题（见图12.2）

形成判断的方法很多

1. 准备工作

2. 帮评估者做好准备

3. 评估

4. 分析与结论

5. 后续行动

表12.3列举了常见的评估目标和展示内容

除此之外，还要制定评估准则，搜集评分所需的数据。另外，还需要制定研讨会议程和准备相关资料

评估者应当关心系统，同时擅长发现细节问题

理想的人选应该精通行业知识和领域知识，或者对采用的技术、模式有专业见解

架构评估至少需要两位评估者。如有必要，最多可以邀请几十位评估者

项目背景、关键架构需求、待评估的架构设计等。

你要回答评估者就项目背景、评估准则、评估目标提出的问题

准备好白板

场景排查（见第17.8节）是最常用的方法，也是最基本，最可靠的架构评估方法

问题-评论-关注事项（见第17.5节）是一种可视化的头脑风暴方法，可以帮助评估者迅速了解架构信息，发现疑点

风险风暴（见第17.6节）也是一种可视化的头脑风暴方法，常用于发现系统特定视图中存在的风险

绘制草图作比较（见第17.9节）可以用来比较不同方案的优劣（如比较提升同一质量属性的多种方案）

代码评审（见第17.2节）不太容易发现架构问题。但它可以识别代码与架构不一致的地方。代码评审也常常用来检查代码中的静态结构

如果已经有了架构决策记录（见第16.1节），那么可以借助它回顾设计决策并确定这些决策是否仍然有效。架构决策记录也可以用来评估适用性

经验丰富的小团队（约三四个人）能够在60分钟内借助“问题-评论-关注事项”方法做出有效的判断

而缺少经验的团队可能要先花时间回顾质量属性场景和设计决策，才能取得较好的效果

除了得出架构是否合格的结论，我们还希望了解如何改进架构设计

结论应该清晰描述架构满足指标的程度，同时提出改进架构的建议

除了判断架构是否满足要求，还应该分析架构为什么不满足要求，以及如何改进

把研讨会收集的数据共享给大家，请大家寻找规律

让大家就存在疑问的地方自由提问

通过开放性的提问环节找出大家对架构理解的差异

给问题排定优先级，把待解决的问题和值得研究但不紧急的问题区分开

可以指定一个人决定针对高优先级的问题接下来应该怎么做

小型研讨会可以群发邮件，写明后续行动要点

大型研讨会可以撰写一份简要的报告，并附上原始会议记录的链接

我们每天都有机会确认（或修正）设计决策

他发现不同类型的测试适合发现不同的bug。有些测试容易创建和维护（主要是单元测试），但这类测试无法捕捉所有bug，所以还需要补充一些复杂、运行较慢的集成测试

大部分架构评估都能快速完成。对于快速评估无法发现的问题，可以补充少量深度评估。除了快速评估和深度评估，还可以采用定向评估

一般的系统大约需要开展一两次深度评估、几十次定向评估、几百次快速评估

如果你想改善架构评估的效果，有一个简单的方法，那就是多问一些之前没有问过的问题

试着提出不同类型的问题，你才能知道自己有多么“无知”

仪式感强的方法有很多约束，成本高，但其可复用性好，可以保证较好的效果

仪式感弱的方法不拘小节，规矩少，易于上手，使用成本低，缺点是使用范围窄，难以保证效果

举一个例子：做完白板涂鸦（见第15.9节）后，把大家留下一起做评估。你先起个头：“看起来我们的进展很不错。大家看看还有什么办法可以提升这个质量属性？”把大家的发言记到白板上。跟大家一起总结新的发现，然后确定下一步的行动。这样不到十分钟时间，就能完成一次临时的架构评估

比如你可以邀请一位同事和你一起做设计。如果你想理解某个模型，也可以邀请一位同事做白板涂鸦（见第15.9节）。在与利益相关方讨论质量属性时，也可以带上一位同事。

在团队评审一份决策文档之前，你最好先找一位团队成员一起看一遍

我们在学校里都体验过支架方法，比如详细批改的试卷和作业、老师制作的辅导讲义、家庭作业模板等

为常见的设计任务简历模板

在代码评审中给出建设性的意见

为新组件搭好代码框架

对设计任务设定期望，并举例解释什么是好的设计，什么是糟糕的设计

为各种思维模式和设计任务建立检查清单，帮助团队成员建立架构思维

架构导轨既可以简化设计（见第5.1节），也可以为团队创造安全的实践机会。

架构导轨降低了破坏架构的可能性

设计方针就是一种简单的架构导轨

另一种常用的架构导轨是要求使用指定库

最严格的架构导轨是融入代码的约束（见第8.3节），在这种情况下开发人员很难再犯错的

交流会时间不必很长，见缝插针的开几次短会跟开长会的效果一样好

为了提高交流效率，应该提前把讨论涉及的知识点传授给大家，避免出现临阵磨枪的现象

这是好事，应该鼓励大家这样做

团队成员愿意分享改善架构的建议，说明你的付出有了回报，这时你可以考虑让他们承担更多的设计任务了

恰当的下放权限能增强团队信心、活跃开发气氛、提高敏捷性

下放的权限太少可能会破坏团队信任，让团队成员觉得束手束脚

下放的权限太多则可能造成团队焦虑，设计结果页难以令人满意

这样做很可能会破坏团队信任、造成严重的返工

更糟糕的是，如果你没能及时发现其中的问题，有可能造成无法挽回的损失

第一级：告知

第二级：贯彻

第三级：咨询

第四级：商定

第五级：建议

第六级：审查

第七级：委托

如果你仍有疑虑，可以先保留设计权限，等到合适的时机再下放权限

遗憾的是，前三级权限在增强团队信心，活跃开发氛围，提高敏捷性方面作用有限

也许你觉得这样做还不如自己设计架构来的轻松。从短期来看，这样想有道理。但从长远看，这会造成团队成员无法成长。如果团队里只有你一个人能设计架构，那么你的知识、能力、精力将成为整个团队的瓶颈

架构师身上的担子很重

优秀的架构师不能只靠自己做决策

如果用团队的策略质量衡量架构师的工作成果，那么架构师也应当致力于帮助开发人员做出更好的决策

无论是梳理技术愿景、指明约束，还是共同确定架构原则，都需要架构师具备一种非技术能力：软技能，这种能力往往很难学到

有一类架构师，他们独来独往，只想研究专业技术，不希望别人干涉自己的架构设计——这些人应该回到象牙塔里去。如果你不想成为这样的架构师，就必须提升自己的技术管理能力，加强自己与团队的合作与联系

这时就可以开展设计研讨会了。你可以在后四级权限里挑选你认为最合适的方式来开展研讨会。把更多的设计权限下放给团队，你将逐渐从架构的设计者变成架构设计的促进者

向团队讲述架构故事，鼓励团队成员一起讲述与架构有关的故事（见第15.1节和16.10节）

开展研讨会，鼓励团队成员参与架构设计（见第九章，第17.5节，第17.6节，第17.8节）

检查团队的参与程度，了解进度（见第17.1节，第17.7节）

如果有好的案例，可以把制作文档的任务下放给团队。

架构师要负责定义关键架构需求，特别是质量属性

架构师要引导团队识别有利于提升既定质量属性的模式

架构师要从全局的角色把握架构设计，同时带领团队完成系统开发

放弃一些东西换取其他东西在软件开发中很常见，架构师要找出备选方案，与各方一起协商如何取舍最合理。

架构师要识别技术债务，制定偿还策略

架构师要提高团队的架构设计能力（包括理解、探索、展示、评估架构的能力），让大家对系统形成共同的责任感

给定或选定的不可更改的设计决策

外部可见特性，表征系统在特定环境下的运行情况

架构设计需要特别注意的特性和功能

时间、知识、经验、技术、办公室政治、你的技术特长，以及其他影响决策的东西

参与者只能挑选一个选项，但这不意味着接下来只做这一件事，而是希望借此澄清问题，解决分歧，避免不必要的麻烦

逐一解释每个选项的含义，确保每个人都能理解

找出所有参与者都认同的选项，达成共识

讨论往往比最终结果更重要

表14.1

图14.1权衡滑块

图14.2

另一种常用的模式是：聆听、观察、行动（或表达）、思考（或感受）

如果有人无法出席会议（如微型质量属性研讨会，见第14.7节），这个方法就能派上用场。这时我们不再描述缺席者的任务、口头禅、想法，而是考虑对方会如何评估特定的质量属性，当然，直接问当事人是最有效的方法，但是当他们缺席时，这样做不失为一种办法。

大家设想出至少两个质量属性场景，或者某个质量属性让人担忧的地方。用记点投票的方式模拟缺席者对质量属性的评估。条件允许的话，事后应该询问缺席者是否认可模拟的评估结果，如果缺席者也无法参加后续会议，模拟的评估结果可以在这些会议中代表缺席者的观点

图14.3是在架构师Thijmen de Gooijer主持的一次研讨会拍下的照片。便利贴上记录的是原始的质量属性场景。白板上画的是质量属性网络（见第14.6节），它展示了系统的各项质量属性。网络中间的环形线条代表缺席者对各项质量属性的态度。质量属性网格用可视化的方式表现各种质量属性的重要程度，尤其适合做头脑风暴时使用。在这次研讨会上，与会者借助移情图模拟缺席者对质量属性进行了评估

目标描述了必须满足的概念性需求。目标可以是质量需求场景、一般软件质量、业务目标等

问题是用于检测一个或多个目标的手段

指标则定义了回答一个或多个问题所需的度量方式

图14.4

比如：比起在一旁监督仓鼠驯养员却没有喂养仓鼠经验的Beatrice，我们更应该询问仓鼠驯养员Eunice

可以使用 响应度量稻草人（见第14.9节）

架构师：你们曾提到新系统会替代现有系统。那么打算如何处理旧系统呢？

利益相关方：新系统上线后，我们就会开始执行迁移计划。整个迁移大概需要9个月时间，因为我们要留出足够的时间让客户放弃旧系统

架构师：9个月相当长。你们预计什么时候完成所有迁移？

利益相关方：当然是越早越好。我希望最迟在明年12月份完成

架构师：好的。那就是说新系统必须在明年三月底前上线。是这样吧？

利益相关方：是这样，没错

架构师：关于迁移的需求，还能再说的详细些么？我不希望留下隐患

利益相关方：当然可以。在迁移前，新系统必须包含四项功能·······

图14.5假设清单

图14.6 质量属性网络

软件工程研究所的网站上有一篇论文《Quality Attributes and Service-Oriented Architectures》，其中给出了一组适用于面向服务架构（SOA）的质量属性分类方案。现成的质量属性分类方案将有助于大家开展头脑风暴

图5.1

图14.6

图5.1

表14.2

1. 头脑风暴与场景优先级排序

2. 完善场景

3. 请利益相关方审核结果

图14.9

但是有人认为五个为什么无法精确定位问题，应当抛弃，使用鱼骨图更合适

云顿市长希望降低30%的采购成本，以避免在选举年削减教育或其他基础服务的预算

云顿市长希望提升本地企业的参与度，因为本地企业中标可以改善本地经济

预算办公室希望将发招标时间缩短一般，从而改善整个城市的服务，同时降低成本

1. 设计意图描述软件对最终用户的影响

2. 业务目标声明简单而直接的描述利益相关方如何从软件系统获得价值。

锚定效应是一种认知偏差，即人们被听到的第一个信息左右。

表14.4

图14.11

我们的服务是变幻无常的。他们不关心自己住在哪里，也不关心每次请求时与哪个服务实例对话

大部分服务都很固执。如果请求失败，他们会继续发出请求

有些服务是急性子，脾气不好。它们不愿意等待，如果不能马上得到想要的数据，他们宁愿凑合使用自己有的数据

有些服务的私人关系很好，互相交流非常频繁。可以考虑成对部署，这样它们就不会孤单了

图15.1

这一系列模型构成了一个不断增长的概念图（见第15.4节），最终形成了一个RESTful风格的API。留意它是如何从基础功能需求起步，然后顺势发现未提及的隐藏想法的。从第6步开始出现了分支，目的是为了探索其他设计路径

图15.3

我们摆好卡片后，发现了一些有趣的地方。首先，Transformer卡片（转换器卡片，在左起第二列）的功能与协作者似乎都太多了。如果把这些功能分配给其他的元素，会发生什么，请看图15.4

我们把原来的Transformer卡片放到以便，将其功能一分为二。新的Transformer卡片只负责转换数据。又增加一张新卡片Training Prep（训练预处理），负责对要训练的数据进行预处理，然后交给训练器（Trainer）。另外，我们还确定了一个新元素，叫训练监视器（Training Monitor），但它与当前业务流无关

再看看这个模型，Training Data Repo卡片（训练数据仓库卡片，位于第三列顶部）似乎也承担了过多的功能。这些功能可以合理的转移到新元素上吗？

我们发现，可以把所有写用户数据的功能从Training Data Repo卡片中移除，只让它处理工作流。我们将Training Data Repo卡片放到一边，然后新增了一张Jobs Service卡片（工作服务卡片，位于图15.5左起第三列顶部）

拍照存档后，我们又引入了一个场景，通过调整CRC卡片支持这个新场景

如果我们对领域模型的了解不充分，就有可能出现概念缺口。概念缺口很容易发现，因为如果不引入新的概念，就无法满足场景。

万能概念是一种神奇的概念，它似乎可以与所有概念相连（包括那些无关的概念）。找出万能概念需要对问题领域和概念图进行高度反思

图15.6

这张图提供了不少有用的信息，它展示了我们对业务规则和系统有效状态的理解（或者叫假设）。我们发现招标书是最重要的领域概念，应该今早定义好这个概念，避免以后出现问题

图15.7

说明探索的基本规则，并设定每个小组每次迭代后要反馈的内容。最重要的规则是，当所有小组聚集在一起反馈时，每个人都应当一五一十的进行分享（无论他发现了什么）

让大家自行组成二到四人的小组。每位参与者都应当属于一个小组，每个小组都应当有一项明确的任务

划分探索空间既可以采用广度优先的方式，也可以采用深度优先的方式。

如果你对通用的解决方案有信心，希望进一步优化它，可以采用深度优先的方式

如果你希望快速降低各个区域的风险，可以采用广度优先的方式

题型大家每次迭代完成后，所有小组要参加展示与说明会议，分享自己的发现

探索任务约定了小组具体要探索什么内容，目标是什么。在展示与说明会议上，所有小组都要展示自己的探索结果，或者解释是什么阻碍了目标的完成

小组可以自行选择合适的方式进行探索。架构师应该时不时检查每个小组的进展情况

每个小组展示探索目标和成果，并简要总结他们学到的东西。其他小组可以提问或给出建议。注意记录大家提出的新问题和风险

某团队的核心任务是创建一组基于云的微服务，前提是尽可能复用原有系统的核心组件。团队花了三周时间探索原有组件的可复用性，以及选择哪些新技术

表15.1展示了第一周的探索任务，以及展示与说明会议上的分享内容

第一小组完成第一周的探索后，决定继续探索原有组件的潜在风险。第二小组和第三小组则重新进行了组队

第三次迭代时，各小组已经习惯了这种快节奏的探索和反馈方式。第三周的展示与说明非常具体

第三周结束时，团队已经成功降低了项目风险，可以开始针对具体的微服务进行详细设计了

第一，事件风暴要求所有参与者积极参与。这意味着领域专家不得不在活动中运用他们的知识

第二，事件风暴鼓励参与者尽量做到详细具体。如果你身边恰好有领域专家，请鼓励他们用清晰的细节描述他们的工作和专业知识

比如：本次研讨会的目标是画出仓鼠生产线系统的事件图

领域事件（橙色）

用户命令（蓝色）

外部系统事件（紫色）

耗时（绿色）

结果（白色）

问题、评论、关注事项（粉色）

你可以这样说：“我们希望各位参与者都贡献自己的想法。请大家积极地用便利贴提出事件和想法，不要犹豫。”

会议主持人应该率先在白纸上贴上便利贴，用这样的方式宣布活动开始。一旦墙上出现了第一个事件，活动就正式开始了

如有需要，可以移动已有便利贴，以便腾出空间放置新发现的事件。还可以在已有事件下增加分支事件

比如便利贴在事件流中的位置是否正确，或者是否误将某个抽象的概念当成了事件。发现有问题的便利贴，可以将它旋转四分之一周，让它看起来像个菱形

帮助参与者找到自己能有所贡献的区域，指出需要关注的热点。活动进展顺利的话，在外人看来应该是略显混乱的

有没有看起来不伦不类的、需要完善的概念？是否存在逻辑漏洞和严重缺陷？

例如，可以拿掉第一张图上的中心概念；或者鼓励参与者采用更具体的描述方式；或者请大家安静的重新构建一张图，尝试把那些之前没能记在便利贴上的想法表现出来

给事件图和便利贴拍照，保存起来。事件图和探索过程中发现的成果可以用于更深入的领域建模

如果没有了解情况的领域专家参与，不妨推迟活动，等有合适的人选再进行。如果全是开发人员参与，得到的只能是技术模型。领域专家与开发人员合作才能创建出可视化的事件流，这才是你需要的

大家对这些东西的需求很可能超出你的想象

多准备写大白纸。如果决定在白板上画图，那么请准备一块足够大的白板

例如：“能举一个例子吗？”“你这里指的是什么意思？”对方的回答通常包含重要的内容

构建新系统或新项目时，需要具备大局观，应该请尽可能多的利益相关方参与

通过挖掘垂直领域，可以收集实现事件溯源和CQRS系统所需的细节

邀请用户体验专家参与，在事件图上叠加一层用户流程

事件图可以用来发现系统中需要扩展和重构的区域，并充当评估材料

可以邀请新同事和利益相关方一起参与活动，借此向他们传授领域知识

图15.8 团队海报

第一轮，参与者围成一圈，各自画出一副草图

第二轮，流转交换草图，参与者要评判同伴的草图

第三轮，再次流转交换草图，参与者尝试解决另一位同伴草图中存在的问题（见图15.9）

鼓励创新

直接把意见写在纸上

时间5分钟

大家一起针对所有的草图开展讨论

图15.10

在他解释的同时，其他人可以在白板上添加新想法。如此循环

在白板上写下必须要解决的问题

白板涂鸦一般都适合采用CSC迭代（见第9.1.3节）的方式进行

草图能唤起参与者的记忆，但对那些不在场的人来说是没有意义的。因此活动中的讨论比草图更重要

图15.11

该决策将对团队或其他组件产生直接的影响

该决策将影响系统中的一个或多个质量属性（无论好坏）

该决策是由业务原因或技术约束引发的

该决策对系统具有深远的、重大的影响，比如框架或技术的选择

该决策将从根本上改变团队开发系统或发布系统的方式

表16.1

如果某个决策被取代或发生了变更，应该在新文件里给出原决策记录的编号

表16.2

这里使用的架构决策记录模板是有Micheal Nygard设计的，网上还有许多类似的例子

近年来出现了许多架构决策记录模板，例如Jeff Tyree和Art Akerman在他们的文章《Architecture Decisions：Demystifying Architecture》中设计了便于根据问题追踪决策的模板，Uwe Van Heesch、Paris Avegerioum、Rich Hilliard在文章《A documentation framework for architecture decisions》中设计了可以再IEEE 42010标准下使用的模板

简要描述整体解决方案

与核心功能需求有关的重要技术约束清单

重要的质量属性清单

简要解释设计决策，包括逻辑依据和取舍原因

架构风格与架构模式

表16.3

图16.1

标题

概述

警告

图16.2

1. 要解决什么问题？

2. 愿景是什么？

3. 实现什么价值？

4. 项目范围是什么？

5. 关键的利益相关方是谁？

6. 基本的解决方案是什么？

7. 主要风险是什么？（什么会导致项目失败？）

8. 有多少工作量？成本多少？

9. 根据什么进行权衡取舍？

10. 何时交付？

例如，一个两周的项目不能花一周时间写启动计划书；而一周时间很可能不足以为一个大型的、多团队项目制作启动计划书

https://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/

树的根节点是系统。

输的每个层级都对某个模块进行分解，展示更多的细节。

在大型系统中，末端的叶子节点可能代表由某个团队负责实现的模块

在较小的系统中，末端的叶子节点可能代表架构中的包或类

图16.3

图16.4

该项目要求软件安装包能够与快速演变的云平台持续集成。该软件安装包每季度更新一次。决策的重点是解决两个平台的集成

最后项目组决定为高优先级的用例提供示例代码。团队不负责维护示例代码。客户可以自己选择使用示例代码，或者对它进行扩展。利益相关方认为这样做在成本和价值之间取得了恰当的平衡。先发布最小可行版本，让产品经理收集关于集成有效性的数据，再决定如何修改框架

表16.4

1. 定义原型的学习目标和范围

2. 确定制作原型的预算和时间

3. 确定结果的交付方式

某团队需要了解Apache Solrg API的性能瓶颈。为此，一位开发人员花了一周时间用Apache JMeter开发了一个简单的测试程序，通过几次负载测试，收集了数据，并撰写了一份两页纸的总结报告。使用Apache JMeter让团队以最低成本快速完成了对数据的收集

某团队要在两个服务端web框架中挑选一个。为此，团队分别利用这两个框架实现了简单的博客应用程序，总共耗时两天。最后，团队通过对比原型的优缺点，选择了其中一个框架

图16.5

图16.6

只针对系统的单个视图

只针对一种结构

对设计决策提供清晰的指导意见

阐明系统属性

基于团队的共同的经验

推论：好隐喻也需要清晰的说明

电影《报童传奇》讲述了1899年纽约市报童罢工的故事。那时，报童每天早上从分发中心购买报纸，然后再卖给纽约市民。我们的爬虫线程就像报童一样——每个线程访问一个分发中心，向数据库请求获取一些行数据，经处理后加入索引。未获取的数据暂时不予记录。就像报童第二天可以继续卖报纸一样，爬虫也可以继续抓取数据，从而补充遗漏的数据

只针对系统的单个视图

只针对一种结构

对设计决策提供清晰的指导意见

阐明系统属性

基于团队的共同的经验

做报告的时间不应超过30分钟，剩下的时间给听众提问和反馈意见

以及听报告的基本要求

若在规定时间内没有完成，也应该停止报告

团队成员可以帮助架构师回答问题

我们要解决什么业务问题?

概述和背景

关键质量属性

关键设计决策及逻辑依据

还考虑过哪些方案

当前进度：质量、余下的工作、下一步的行动

成本

最大的风险和其他需要注意的地方

未来计划

https://github.com/stuarthalloway/presentations/wiki/Architectural-Briefings

稍后的示例给出了评审过程中你需要关注的方面。

例如，如果发现同事存在理解偏差，可以采用结对编程或白板涂鸦（见第15.9节）解决

正确性

一致性

可测试性

可修改性/可维护性

可靠性

可伸缩性

比如，只有运行测试，才能对性能和可用性进行量化

如果有大量备选方案，则应该使用多个矩阵

你的分析可以作为决策依据，它与结果一样重要

表17.1

他们开发的Hystrix Dasboard可以用来观察Hystrix容错库生成的指标。Simian Army则可以用各种方式刺激面向服务的系统

这些平台包括Loghide、Splunk、Graglog。你可以挑选一个来存储和分析系统事件。请记住，尽管这些工具非常强大，它们的作用在很大程度上取决于你的系统设计

图17.1

例如：寻找风险，并确定风险的严重程度，以便决定接下来采取什么行动

所有人都应该参与在白板或纸上画架构草图（由若干视图组成）

用不同颜色的便利贴代表风险的严重程度。

风险的严重程度由其发生的可能性、后果、时间共同决定

图17.2

图17.3

架构师最了解架构设计，他负责描述系统如何对刺激做出响应

记录员负责做速记，他要记下会议期间提出的所有问题、风险、盲点、认知偏差和其他一般性问题

朗读者朗读场景介绍，辅助场景排查。他同时也是会议主持人

一位或多位评估者。评估者是利益相关方或第三方的专家，他们在评审期间提出问题，找出架构中的漏洞。记录员和朗读者也可以担任评估者

我们的目的是在架构设计尚未定型前发现问题，避免返工

会议的目的是发现问题，而不是解决问题

场景介绍：用户搜索公开的招标书，一年中平均99%的时间应该可以搜到可用的招标书列表。

为了排查这个可用性场景，我们需要一些条件。回忆一下，LionHeart·项目包含少量的web服务、几个数据库和一个搜索索引

图17.4是待排查的质量属性场景

春天市IT部门决定将LionHeart·项目托管在云端，并且同时托管在两个不同的云服务区的Docker容器里。这样，当A区失效时，B区仍然可用（见图17.5）

朗读者：接下来的场景是某云服务区时效期间系统的可用性。假设一切运转正常，突然，A区的云服务失效了

架构师：负载均衡器将在60秒内检测到故障，并自动将流量导向可用的B区。如果某个用户不幸在这个时候访问网站，他会收到访问失败的提示。只要他再次刷新浏览器，应该就可以正常访问了

评估者1：负载均衡器托管在哪里？

架构师： 就在对面的机房里

评估者1： 就是说所有的访问请求都是由我们这里的负载均衡器决定的？那它岂不是成了系统最薄弱的缓解？如果是这样的话，还要云服务器做什么？

朗读者：请注意评论应该具有建设性，你能把你的担忧用风险的形式表述出来吗？

评估者1：对不起，这样说吧，我们的多区云服务器存在单点故障隐患，这可能无法满足需求。（记录员做记录）

评估者2：在这种多区域部署的情况下，如何保证数据是最新的······

图17.6