一线架构师经常面对的实践困惑，可以用下面的图来概括。其中，涉及了“4个实际问题的困惑”，以及“两个职业发展的困惑”。

画龙须点睛 。

在介绍具体方法之前，先阐述4个核心主张。

这4个核心主张可帮助读者领会ADMEMS方法之精神。

单一方法已经无法解决复杂的业务需求，一线架构师真正需要的是覆盖“需请进，架构出”全过程的实践指导。

只有综合了不同方法优点的“方法体系”才能堪此重任。

ADMEMS是“Architectural Design Method has been Extended Method System”的缩写。ADMEMS并不是单一方法，而是由多个各具特点的方法组成的方法体系。

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

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

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

缺点儿什么呢? 答案是，缺“人的因素 ”、“架构师的因素 ”!

接下来将不断阐述架构设计实际上是个“质疑驱动的过程 ”:

需求，被架构师的大脑(而不是自动)，有节奏地引入到架构设计的一波接一波的思维活动中。

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

质疑意识，是架构师最宝贵的意识之一。

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

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

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

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

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

ADMEMS方法融入了哪些实践？

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

上面的图基本上说明“3个阶段 ”在整个方法体系中的位置。具体而言：

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

“1个贯穿 ”，指的是对非功能目标的考虑。

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

概念架构 ≠ 理想化架构 。所以，必须考虑包括功能、质量、约束在内的所有方面的需求。下图是推荐的概念架构设计的步骤。

细化架构是相对于概念架构而言的。 细化架构阶段的总体方法为5视图方法 。

许多架构师，言架构必谈OO。在他们的思想里面，认为OO方法已经完整覆盖了架构设计的所有方法和技巧。这种看法，是相当片面的。

弱OO方法已涵盖架构设计的全部，那么5视图方法 所涉及的逻辑架构 、物理架构 、开发架构 、运行架构 、数据架构 ，都应受到OO方法的指导，然而并不是这样。

上面图中说提到的物理架构、开发架构、运行架构和数据架构者4个架构视图，分别是面对节点、面对文件、面对控制流和面向Table（或文件）的 -- 也就是说，一般认为这4个架构摄图主要的思维并非OO思维。

另一方面，即使是逻辑架构的设计，也未必是以OO方法为指导的。应该将逻辑架构设计总结为 “面向职责” 更贴近本质。

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

ADMEMS方法应对非功能需求的思维工具，目标-场景-决策表 可以将架构师的思维可视化出来。

那么，如何运用本书解决之前提到的“6个困惑”呢？

如果，你是一个已经有一定实践经验的架构师，希望更加合理地对系统进行模块切分，请关注“第三部分 Refined Architecture阶段 ”。你将了解到，划分子系统的4大原则。

如果，你是一个已经有一定实践经验的架构师，希望更加合理地对系统进行模块切分，请关注“第三部分 Refined Architecture阶段 ”。你将了解到，划分子系统的4大原则。