Refined Architecture阶段
一、 Refined Architecture
先作者给出Refined Architecture的概念：它是相对于Conceptual Architecture而言的，它们是架构设计的两个层次，分别对应于“概念级”解决方案和“规约级”解决方案。细化架构属于架构设计，不能与详细设计相混淆。接着讨论了它的实际意义： 1、利于思考（因为分而治之的思维方式）；2、便于交流（因为在一定程度上分离了涉众关注点）。 之后介绍了它的业界现状：1、误认为多视图是OO方法分支;2、误将“视图”当成“阶段”; 3、RUP4+1视图；4、SEI3视图；最后给出了它的实践要领 。
二、 逻辑架构
架构设计单单是需求驱动的说法不太完善（根据需求不可能自己生成架构设计），还需要“人的因素”、“架构师的因素”。 本书认为架构设计是个“质疑驱动的过程”：需求是被架构师的大脑有节奏地引入架构设计一波接一波的思维活动。架构设计中需要由“质疑”脑参与，质疑意识，是架构师最宝贵的意识之一。本章阐释ADMEMS 5视图方法中逻辑架构视图的设计:先从划分子系统的3种必用手段讲起;随后，纠正“我的接口我做主”这种错误认识，代之以“协作决定接口”的正确理解;而且，本章将解析逻辑架构设计的整体思维套路，解决一线架构师郁闷已久的“多视图方法只讲做什么、不讲怎么做”的问题:最后，总结逻辑架构设计的10条经验要点。
三、 物理架构、运行架构、开发架构
首先讨论了物理架构的必要性：增加硬件=增加计算能力，不等于软件的实际服务能力增强。从最终目标层面，决策要兼顾多方涉众的不同利益，可从“攻”与“守”两个方面理解:1、高性能(攻)2、持续可用性(攻)3、可伸缩性(攻)4、经济性(守)5、技术可行性(守)6、易维护性(守)。
四、 划分子系统的3中必用策略
分层的细化： 这里最经典的就是MVC架构的三层分层：展现层，逻辑业务层，数据访问层。这三层是紧密联系在一起的，但又是互相独立的，每一层内部的变化不影响其他层。每一层都对外提供接口（Interface），供上面一层调用。这样一来，软件就可以实现模块化，修改外观或者变更数据都不用修改其他层，大大方便了维护和升级。
分区的细化： 但是这三层过于笼统，并不利于支持团队的并行开发开发，所以引入了分区的概念。将区作为一个单元，减小它的细粒度，从而使得工程师能够更好的进行迭代开发。就比如在解压软件当中，如何将展示层进行分区，我们首先要明白，解压软甲会有那些展示界面：主界面，解压/压缩进度界面以及嵌入在系统中的右击命令界面。那么我们很容易的将其展示区分为三个界面。
机制的提取： 在解压软件中，无论是数据层和业务逻辑层，都需要对缓存进行智能的管理。他们之间不仅包含了协作关系，同时也包含了协作流程。我们需要对这个缓存机制进行一个相应的提取，这样有利于缓存的管理。同时也是减少重复代码片段，虽然语句直接比较并不相同，但是很多语句只是引用的变量不同，更重要的是语句块结构完全相同，提取机制，更多的变现为基于抽象角色编程。