第1章 绪论
软件架构在不断发展，但它仍然是一个尚不成熟的学科。
——Len Bass，《软件构架实践（第2版）》
推动软件工程研究不断发展的，常是实际生产或使用软件时遇到的难题（Software engineering research is often motivated by problems that arise in the production and use of real-world software）。
——Mary Shaw，《The Golden Age of Software Architecture》
架构设计能力，因掌握起来困难而显得珍贵。
本章概括一线架构师经常面对的实践困惑，并点出ADMEMS方法的应对之策。
1.1 一线架构师：6个经典困惑
一线架构师经常面对的实践困惑，可以用图1-1来概括。其中，涉及了“4个实际问题的困惑”，以及“两个职业发展的困惑”。
图1-1 一线架构师的6个经典困惑
1.2 本书的4个核心主张
画龙须点睛。
在介绍具体方法之前，先来阐释本书的4个核心主张：
■ 方法体系是大趋势。
■ 质疑驱动的架构设计。
■ 多阶段方法。
■ 内置最佳实践的方法。
这4个核心主张可帮助读者领会ADMEMS方法之精髓。
1.2.1 方法体系是大趋势
单一方法已捉襟见肘。一线架构师真正需要的，是覆盖“需求进，架构出”全过程的实践指导——只有综合了不同方法优点的“方法体系”才堪此重任。本书认为，方法体系必然是软件业界未来发展的重大趋势之一。
本书将要系统介绍的方法体系的名字——ADMEMS，正是“Architectural Design Method has been Extended to Method System”的缩写。是的，ADMEMS方法不是“单一方法”，而是由多个各具特点的方法组成的“方法体系”。ADMEMS方法通过它的名字亮明了其核心主张。
ADMEMS方法命名由来
ADMEMS是“Architectural Design Method has been Eⅹtended to Method System（架构设计方法已经扩展到方法体系）”的缩写。
1.2.2 质疑驱动的架构设计
从根本上讲，架构设计毫无疑问是需求驱动的，而不是模型驱动的。
但需求驱动的说法不太传神——当你很清楚需求却依然设计不出架构时，就足以说明“需求驱动的架构设计”的总结还“缺点儿什么”。
架构设计是一门艺术，你不可能把“一桶需求”倒进某台神奇的机器，然后等着架构设计自动被“加工生产”完毕，因此“需求驱动的架构设计”的总结给架构师的启发不够。
缺点儿什么呢？答案是缺“人的因素”、“架构师的因素”！
本书将不断阐释架构设计实际上是个“质疑驱动的过程”：需求，被架构师的大脑（而不是自动）有节奏地引入架构设计一波接一波的思维活动中。例如，作为架构师，当你的架构设计进行到一半时，你可以明显感觉到：这个架构设计的中间成果，还须要进一步通过“质疑”引入更多“质量属性”，以及“特殊功能场景”来驱动后续架构设计工作的开展。
在保留“需求驱动的架构设计”所有正确内涵的同时，“质疑驱动的架构设计”告诉架构师：你的头脑，才是架构设计全过程的发动机。质疑意识，是架构师最宝贵的意识之一。
至于有的专家提倡的“用例驱动的架构设计”观点，则有严重缺陷，3句话足以揭示这一点：
■ 需求=功能+质量+约束。
■ 用例是功能需求的实际标准。
■ 用例涉及、但不涵盖非功能需求。
1.2.3 多阶段还是多视图？
架构设计的多视图方法很重要，但是，架构设计方法首先应当是多阶段的，其次才是多视图的。如图1-2所示。
图1-2 架构设计方法首先应当是多阶段的，其次才是多视图的
一句话，先做后做——这叫阶段（Phase），齐头并进——这叫视图（View）。
本书认为，任何好的方法（不局限于软件领域），都必须以时间为轴来组织，因为这样才最利于指导实践。
架构设计只需多视图方法，看上去很美，其实并不足够。实际上，大量一线架构师早已感觉到多视图方法的“不足够”。例如，想想投标：
■ 一方面，投标时，要提供和讲解《方案建议书》，其中涉及架构的内容。
■ 另一方面，团队并行开发时，需要《架构设计文档》供多方涉众使用。
■ 但是，投标时讲的“架构”和并行开发时作为基础的“架构”在同一个抽象层次上吗？绝不可能。前者叫概念架构，后者叫细化架构。如果投标失败，细化架构设计根本就不须要做了。
■ 结论，概念架构设计和细化架构设计，是两个架构阶段，不是两个架构视图。
1.2.4 内置最佳实践
方法不应该是个空框框，应融入最佳实践经验。相信业界很多专家都正朝着这个方向迈进。
ADMEMS方法中融入了笔者的哪些实践经验呢？仅举几例：
■ 逻辑架构设计的10条经验（如图1-3所示）。
图1-3 逻辑架构设计的10条经验
■ 质疑驱动的逻辑架构设计整体思路（如图1-4所示）。
图1-4 质疑驱动的逻辑架构设计整体思路
■ 基于鲁棒图进行初步设计的10条经验。
■ ADMEMS矩阵方法。
■ 约束的4大类型。
■ ……
1.3 ADMEMS方法体系：3个阶段，1个贯穿环节
作为方法体系，ADMEMS方法通过3个阶段和1个贯穿环节，来覆盖“需求进，架构出”的架构设计完整工作内容。
图1-5说明了“3个阶段”在整个方法体系中的位置。具体而言：
图1-5 ADMEMS方法体系包含3个阶段
■ “Pre-architecture”阶段（简称PA阶段）。
➢ 最大误区：架构师是技术人员不必懂需求。
➢ 实践要点：摒弃“需求列表”方式，建立二维需求观。
➢ 思维工具：ADMEMS矩阵等。
■ “Conceptual Architecture”阶段（简称CA阶段）。
➢ 最大误区：概念架构=理想设计。
➢ 实践要点：重大需求塑造概念架构。
➢ 思维工具：鲁棒图、目标-场景-决策表等。
■ “Refined Architecture”阶段（简称RA阶段）。
➢ 最大误区：架构=模块+接口。
➢ 实践要点：贴近实践的5视图法。
➢ 思维工具：包图、包-接口图、灰盒包图、序列图、目标-场景-决策表等。
值得强调的是，上述3个阶段之间的先后顺序有极大的实际意义，否则就不能称其为“阶段”了：
■ 试想，在Pre-architecture阶段对需求理解不全面（例如遗漏了需求）、不深入（例如没有发现“高性能”和“可扩展”是两个存在矛盾的质量属性），后续设计怎会合理？
■ 试想，Conceptual Architecture阶段的概念架构设计成果没有反映系统的特点就“冲”去做Refined Architecture设计，是不是必然造成更多的设计返工？
“1个贯穿环节”，指的是对非功能目标的考虑。
1.3.1 Pre-architecture阶段：ADMEMS矩阵方法
Pre-architecture阶段的使命，可以概括为一句话：全面理解需求，从而把握需求特点，进而确定架构设计驱动力。其中，ADMEMS矩阵居于方法的核心。
“ADMEMS矩阵”又称为“需求层次-需求方面矩阵”（如表1-1所示），帮助架构师告别需求列表的陈旧方式，顺利过渡到二维需求观，借此避免遗漏需求、并进一步理清需求间关系和发现衍生需求。
表1-1 ADMEMS矩阵的基础是二维需求观
1.3.2 Conceptual Architecture阶段：重大需求塑造概念架构
概念架构 ≠ 理想化架构。所以，必须考虑包括功能、质量、约束在内的所有方面的需求。图1-6说明了ADMEMS方法推荐的概念架构设计的高层步骤。
图1-6 ADMEMS方法推荐的概念架构设计做法
1.3.3 Refined Architecture阶段：落地的5视图方法
细化架构是相对于概念架构而言的。细化架构阶段的总体方法为5视图方法，如图1-7所示。
图1-7 5视图法：ADMEMS方法的一部分
许多架构师，言架构则必谈OO。在他们的思想里，认为OO方法已完整涵盖了架构设计的所有方法和技巧。这种看法是相当片面的。
分析图1-7。若OO方法已涵盖架构设计的全部，那么5视图方法所涉及的逻辑架构、物理架构、开发架构、运行架构、数据架构，都应全面受到OO方法的指导，然而实际上并不是这样。正如图中所标明的，物理架构、开发架构、运行架构和数据架构这4个架构视图，分别是面向节点、面向文件、面向控制流和面向Table（或文件）的——也就是说，一般认为这4个架构视图主要的思维并非OO思维。另一方面，即使是逻辑架构的设计，也未必都是以OO方法为指导的。例如，大量嵌入式软件和系统软件还是以C语言为主要开发语言，其逻辑架构设计会以结构化方法为指导。如此看来，倒是将逻辑架构设计总结为“面向职责”更贴近本质。
1.3.4 持续关注非功能需求：“目标-场景-决策”表方法
非功能需求不可能是“速决战”，连编码都会影响到性能等非功能属性，更何况概念架构设计和细化架构设计。
作为ADMEMS方法应对非功能需求的思维工具，目标-场景-决策表将架构师的思维可视化了。例如，如表1-2所示的目标-场景-决策表，揭示了大型网站高性能设计策略背后的理性思维。
表1-2 目标-场景-决策表：揭示大型网站高性能设计策略背后的理性思维
1.4 如何运用本书解决“6大困惑”
至此，我们已走马观花地了解了本书要讲的ADMEMS方法的特点。那么，如何运用本书解决章首提到的“6大困惑”呢？
如图1-8所示，针对6个困惑分别给出了阅读路线图。
图1-8 针对6个困惑，不同的阅读路线图
例如，如果你是一个已有一定实践经验的架构师，希望更加合理地对系统进行模块切分，请关注“第3部分Refined Architecture阶段”。你将了解到，划分子系统的4大原则（如图1-9所示）：
图1-9 第3部分Refined Architecture阶段：划分子系统的4大原则
■ 职责分离原则。
■ 通用专用分离原则。
■ 技能分离原则。
■ 工作量均衡原则。
其他问题的解决思路在此不再展开叙述，请大家参照“路线图”阅读相应章节。