绪论

第一章     绪论

        架构设计能力，因掌握起来困难而显得珍贵。

      本章概括一线架构师经常面对的实践困惑，并点出ADMEMS方法的应对之策。

第一节        一线架构师：6个经典困惑 

4个实际问题的困惑	1，将系统划分模块，如何更合理？ 2，大系统架构设计，如何起步？ 3，总觉需求很糟糕，影响了架构设计！ 4，非功能需求重要，但如何设计？
2个职业发展的困惑	1，架构新手：缺乏指导，架构设计不知所措！ 2，架构老手：缺乏总结，仍“怕”下一个项目！

  

第二节    四个核心主张

在介绍具体方法之前，先来阐释本书4个核心主张：

a:方法体系是大趋势

b: 质疑驱动的架构设计

c: 多阶段方法

d: 内置最佳实践的方法

透过这4个核心主张，便于读者领会ADMEMS方法之精髓。

2.1  方法体系是大趋势

      单一方法已捉襟见肘。一线架构师真正需要的，是覆盖“需求进，架构出”全过程的实践指导----只有综合了不同方法优点的“方法体系”才能堪此重任。本书认为，方法体系必然是软件业界未来发展的重大趋势之一。

       本书将要系统介绍的方法体系的名字----ADMEMS, 正是“Architectural Design Method has been Extended to Method System” 的缩写。是的，ADMEMS方法不是“单一方法”，而是由多个各具特点的方法组成的“方法体系”。ADMEMS方法通过它的名字亮明了其核心主张。

2.2 质疑驱动的架构设计

毫无疑问，架构设计是驱动的，而不是模型驱动的。

        但需求驱动的说法，不太传神----当你很清楚需求却依然设计不出架构时就足以说明“需求驱动的架构设计”的总结还“缺点什么”。

         架构设计是一门艺术，你不可能把“一桶需求”倒进某台神奇的机器然后等着架构设计自动被“加工生产”完毕，因此“需求驱动的架构设计”给架构师的启发不够。

         缺点是什么呢？答案是“人的因素”，“架构师的因素”！

        本书将不断阐释架构设计实际上是个“质疑驱动的过程”： 需求，被架构师的大脑（而不是自动），有节奏地引入到架构架构设计的一波接一接的思维活动中。例如，作为架构师，当你的架构设计进行到一半时，你可以明显感觉到：这个架构设计中间成果，还需要“我”进一步通过“质疑”引入更多“质量属性”以及“特殊功能场景”来驱动后续的架构设计工作的展开。

       在保留“需求驱动的架构设计”所有正确内涵的同时，“质疑驱动的架构设计”告诉架构师：你的头脑，才是架构设计全过程的真正驱动力。质疑意识，是架构师最宝贵的意识之一。

      至于有的专家提倡的“用例驱动的架构设计”这种观点，则有严重缺陷，3句话足以揭示这一点：

a:   需求= 功能+质量+约束

b:   用例是功能需求实际上的标准

c:   用例涉及、但不涵盖非功能需求

2.3 多阶段还是多视图？

       架构设计的多视图方法很重要，架构设计方法首先应当是多阶段的，其次才是多视图的。

       阶段1：把握需求特点，确定架构驱动力

       阶段2：根据重大需求，确定概念架构

       阶段3：细化架构设计，关注不同视图

       一句话，先做后做----这叫阶段（Phase）,齐头并进---这叫视图（View）

本书认为，任何好的方法（不局限于软件领域），都必须以时间为轴来组织，因为这样才最利于指导实践。

架构设计只需多视图方法，看上去很美，其实并不足够。实际上，大量一线架构师早已感觉到多视图方法的“不足够”。例如，想想投标：

a: 一方面，投标时，要提供和讲解<<方案建议书>>，其中涉及到架构的内容

b:另一方面，团队开发时，需要《架构设计文档》，供多方涉众使用

c:但是，投标时讲的“架构”和并行开发时作为基础的“架构”在同一抽象层次上吗？绝不可能。前者叫概念架构，后者叫细化架构。如果投标失败，细化架构设计根本就不需要做了。

d:结论，概念架构设计和细化架构设计，是2个架构阶段，不是2个架构视图。

2.4 内置最佳实践

      方法不应弄湿个空框框，应融入最佳实践经验。相信业界很多专家都正朝着这个方向迈进。

      ADMEMS方法中融入了笔者的哪些实践经验呢？仅举几例：

      a:逻辑架构设计的10条经验

         1，划分子系统：分层的细化

          2，划分子系统：分区的引入

          3，划分子系统：机制的提取

          4，协作决定接口

          5，序列图的优点与协作图的问题

          6，包-接口图：从结构到行为的桥

          7，灰盒包图：描述关键子系统

          8，循序渐进的螺旋思维

           9，设计模式：包内结构

           10，设计模式：包间结构

       b:质疑驱动的逻辑架构设计整体思路

               包图-------> 序列图---------->包-接口图--------->（让职责协作起来，验证能否完成功能？功能完成得是否好？）---->完善序列图（行为方面的约定）----->质疑自己的设计，特殊功能场景支持吗？耦合性、重用性咋样？----------->结构方面的切分

        c:ADMEMS矩阵方法

        d:约束的4大类型

                      第3节  ADMEMS方法体系：3个阶段，1个贯穿环节

       作为方法体系，ADMEMS方法通过3个阶段和1个贯穿环节来覆盖“需求进，架构出”的架构设计完整工作内容。

                需求-------------》PA阶段（架构实践中最常见的最短版）----》

                                          CA阶段（大型系统成败的关键）----》

                                           RA阶段（大规模并行开发的基础）-----------》架构

       Pre-architecture阶段（PA阶段）

                 最大误区： 架构人员是技术人员不必懂需求

                 实践要点： 摒弃“需求列表”方法，建立二维需求观

                 思维工具：ADMEMS矩阵等

       Conceptual Architecture阶段（CA阶段）

                 最大误区：概念架构=思想设计

                 实践要点：重大需求塑造概念架构

                 思维工具：鲁棒图，目标-场景-决策表等

        Refined Architecture阶段（RA阶段）

                  最大误区：架构=模块+接口

                  实践要点：贴近实践的5视图法

                  思维工具：包图，包-接口图、灰盒包图、序列图等

          上述3阶段之间的先后顺序有极大的实际意义，否则就不能称其为“阶段”了：

           试想，在PA阶段对需求理解不全面（例如遗漏了需求）、不深入（例如没有发现“高性能”和“可扩展”是两个矛盾的质量属性），后续设计怎会合理？

           试想，CA阶段的概念架构设计成果没有反映系统的特点就去做RA设计，是不是必然造成更多的设计返工？

       

           “一个贯彻环节”，是非功能目标的考虑。

           3.1 Pre-architecture阶段：ADMEMS矩阵方法

          

            Pre-architecture阶段的使命，可以概括为一句话：全面理解需求，从而把握需求特点，进而确定架构设计驱动力。其中，ADMEMS矩阵居于方法的核心。

           “ADMEMS矩阵”以称“需求层次-需求方面矩阵”，帮助架构师告别需求列表的陈旧方式，顺利过渡到二维需求观，藉此避免漏需求、并进一步理清需求间关系和发现衍生需求。

	功能	质量	约束
组织需求	业务目标	快好省	技术性约束 标准性约束 法规性约束 遗留系统集成 技术趋势 分批实施 竞争因素与竞争对手
用户需求	用户需求	运行期质量	用户群特点 用户水平 多国语言
开发需求	行为需求	开发期质量	开发团队技术水平 开发团队磨合程度 开发团队分布情况 开发团队业务知识 管理：保密要求 管理：产品规划 安装 维护

            

      

            3.2 Conceptual Arch阶段：重大需求塑造概念架构

            概念架构<>理想化架构，所以，必须考虑包括功能、质量、约束在内的所有方面的需求。

            3.3 Refined Arch阶段： 落地的5视图方法

             细化架构是相对于概念架构而言的。

             3.4 持续关注非功能需求：“目标-场景-决策”表示方法

              非功能需求不可能是“速决战”，连编码都会影响到性能等非功能属性，更何况概念架构设计和细化架构设计。

              作为ADMEMS方法应对非功能需求的思维工具，目标-场景-决策表漂亮地将架构师的思维可视化了。

第4节，如何运用本书解决“6大困惑”

到此，我们已经走马观花地领略了本书所讲的ADMEMS方法的特点，那么，如何运用本书解决章首提到的“6大困惑”呢？

如果你是一个已有一定实践经验的架构书，希望更加合理地对系统进行模块切分，应特别关注本书第3部分RA阶段。你将了解到，划分子系统的４大原则：

职责分离原则

通用专用分离原则

技能分离原则

工作量均衡原则