Refined Architecture,译为【精致的建筑】。顾名思义，是要建立起一个精细的，美感与多功能并存的建筑。然而建筑本体是一个比较大的框架，其多功能的具体实现还要以后续的方式进行。这一阶段在本书的第三阶段，前两个阶段的内容大致为：pre-Architecture阶段、conceptual Architecture阶段，其名称为【前架构】、【概念架构】。
当一栋建筑的修建目标被确立时，就启动了一系列的进程来实现它。首先我们要明确的是该建筑的用途所在，是要供人居住生存还是办公，亦或是用作纪念观赏。其中每个类型又被分为若干个精确地服务类型。这就是我们的pre-Architecture。
当我们明确了所有需求目标之后，就要到草图来发挥它的作用了。这就是一个整体的概念架构，比如说整个工程的占地面积，高度等等。这在我们的软件开发过程之中也是如此。
试想一下，我们现在完成了大体的工作规划，可是各部门该怎么做？要怎样去落实这一个工程的具体进展？这就到了本文要讲述的阶段——Refined Architecture阶段。
书中提到，Refined Architecture是相对于Conceptual Architecture而言的，它们是架构设计的两个层次，分别对应于“概念级”和“规约级”解决方案。需要注意的是，Refined Architecture属于架构设计，不能和Detailed Design(详细设计)混淆。
在书中的这个阶段，作者提到了细化架构、Refined Architecture总论、逻辑架构、物理架构、运行架构、开发架构、以及数据架构。
一开始作者用了两个小故事来引入我们对细化架构的思考——骄傲的架构师、郁闷的程序员，办公室里的争论。它们都不约而同的指出了细化架构和五视图方法的重要性。正如书中提到：
如果一个项目的系统架构（包括理论基础）尚未确定，就不应该进行系统的全面开发。
如果选择视图的工作没有做好，或者以牺牲其他视图为代价，只注重一个视图，就会冒掩盖问题以及厌恶解决问题（这里的问题是指那些最终会失败的问题）的风险。
五视图：
这五个视图各司其职，各自拥有者自己的使命：职责划分（逻辑视图）、程序单元组织（开发视图）、控制流组织（运行视图）、物理节点安排（物理视图）、持久化设计（数据视图）。
“思考最大的障碍在于混乱。抓住每个视图的思维立足点，5视图的方法就显得相当清楚了”。
五视图详细：
看似复杂的五视图方法其实并不难，因为每个视图都是从特定角度出发规划系统的分割与交互，都是“组件+交互”的体现。
接下来我们要做的事情就是划分子系统了。划分子系统的三种方法：分层的细化、分区的引入（架构中引入分区，支持深度优先的迭代开发）、机制的提取（基于接口（或抽象类）的协作是机制，基于具体类的协作则算不上机制；实现不同的最终功能可以重用同一个机制），及“总-分-总”。
划分子系统的四个重要原则：职责不同的单元划归不同子系统； 通用性不同的单元划归不同子系统； 需要不同开发技能的单元划归不同子系统； 兼顾工作量的相对均衡，把太大的子系统进一步做切分。
分层（layer）的细化：
分区:
定义接口，避免出现“我的接口我做主”的思想，因为这个观点是错误的，每个模块或者子系统（甚至类）无视协作需要进行的接口定义很难顺畅的被其他模块和子系统所使用的。
质疑驱动的逻辑架构设计：
需求对架构设计的“驱动”作用，是伴随着架构师“不断设计中间成果——不断质疑中建成果——不断调整完善细化中间成果”的过程进行展开的。
原文地址：https://www.cnblogs.com/990906lhc/p/12676447.html