Refined Architecture，即细化架构，这是架构的第三阶段，前两个阶段分别是需要全面理解需求的Pre-Architecture（预备架构）阶段和界定系统高层组件关系的Conceptual Architecture（概念架构）阶段。这次的阅读笔记主要理解Refined Architecture。
首先，细化架构是架构三阶段不可或缺的一环，二阶段的概念架构无法代替细化架构来规范和指导程序员开发系统，二者区别主要在于一下三个方面：
1、 接口。概念架构中没有明确的定义接口，而接口在细化架构中处于核心地位。
2、 子系统。细化架构通过子系统和各种模块来分割整个系统，并且子系统之间也明确了接口，而概念架构中只有抽象的组件，并且组件之间也没有接口。
3、 交互机制。细化架构落实模块或子系统之间的交互机制，是相互调用，还是使用API的方法，而概念架构只会说明需要交互的地方，不会说明交互方法。
所以，在概念架构设计阶段，方案是项目、需求和架构的总览，而方案并非架构的全部。
在细化架构阶段，采用多视图方法分析系统，可以将架构师的多项工作分类成五个方面：
1、 运行架构。例如进程、线程的相关设计。
2、 逻辑架构。例如子系统的划分和接口的定义。
3、 物理架构。例如服务器的选型。
4、 开发架构。例如源程序目录结构的定义。
5、 数据架构。例如数据库格式和文件格式的定义。
那么视图究竟是什么？我认为可以类比于小学学过的“三视图”，即正视图、俯视图和左视图。通过三个不同方向的观察，我们可以判断这个物体是否存在，并且想象出物体在三维空间的样子。而架构设计中使用的多视图方法是同样的道理，它要求架构师在不同角度审视系统，结合多角度的审视结果，规划出系统的“模样”，然后交给程序员“打造”。
接下来提到的“五视图”，是作者以4+1视图方法为基础，融合了作者自己的开发实践经验得到的。
五视图及其主要责任如下：
1、 运行视图：控制流组织。
2、 逻辑视图：职责划分。
3、 物理视图：物理节点安排。
4、 开发视图：程序单元组织。
5、 数据视图：持久化设计。
可以如下图看出五视图之间的联系：
从这张图中，我们可以得到的是，无论哪种视图，核心体现都是架构的定义“组件+交互”这样的共同规律。
作为一篇读书笔记，不仅要记录书中的要点内容，更重要的是自己能够思考出什么一些东西。书中提到了多种多视图方法，如RUP4+1视图、SEI 3视图等，而最终，作者讲述的是以RUP4+1视图为基础，结合自己的实践经验改良的5视图方法。事实上，读到这里，我才明白为什么作者在之前强调：“业界早已存在一些有影响力的多视图方法（例如RUP4+1视图方法），但是作为一线架构师，要有意识地调整、扩充、改进经典方法以符合实践的真正需要”。如何服务现实？单单是纯理论，或是被人可描述于书本上的理论是不够的。真实的世界千变万化，也许只是一个小小的参数变化就完全使理论方法不可使用。所以有意识的修改，也许修改有可能是一种倒退，来契合当前面临的难题才是最好的办法。