这一部分开始用两个故事引入，指出了细化架构在实际中的一些差强人意或容易被人忽视的地方
故事：《方案书》确认之后
这个故事讲了在一个项目中，架构师、项目经理、需求分析师结合与客户的沟通意见，合作完成了《方案书》并获得了客户的认可，之后架构师则认为《方案书》得到认可之后就不需要在进行架构设计。但是程序员却遇到了问题，因为他在实际开发中并没有获得足够的指导和限制。
究其原因，是因为概念架构难以支持并行开发，需要提供指导和限制作用更明确的“规约”一级的设计。所以细化架构与概念架构之间的问题就显露出来了。
细化架构与概念架构存在的典型差异：
（1）接口。在细化架构中，接口占据非常核心的地位，而概念架构并不关心明确的接口定义
（2）子系统。细化架构重视通过子系统和模块来分割整个系统，并且子系统往往有明确的接口；而概念架构中只有抽象的组件，这些组件没有接口，只有职责。
（3）交互机制。细化架构中的交互机制应是“实在”的，如基于接口编程、消息机制或远程方法调用等；而概念架构中的交互机制是“概念化”的，例如“A层使用B层的服务就是典型的例子，这里的“使用”到了细化架构中可能基于接口编程、消息机制或远程方法调用等其中的一种。
方案和架构的联系与区别
（1）方案包含一定的架构内容。
（2）方案涉及的架构基本在概念架构一级。
（3）架构设计的工作还远未完成。
因此我们可以得到：方案=“项目+需求+架构”的总览 方案≠架构的全部
故事：办公室里，争论正酣
这个简单的小故事告诉我们架构中需要的框架、接口、建模等等许多视图，不同的涉众看待软件架构的视角是不同的。
贴近实践的多视图方法，应将一线架构师的各项具体工作涵盖其中。
在Refined Architecture总论中，作者向我们展示了细化架构与概念架构的区别，及支持细化架构设计的整体思路——多视图方法。
从上图中可以看懂两者的区别，细化架构是在概念架构的基础上进行的更深一层的设计及约束
多视图，就类比于建筑设计图中的功能视图以及布线视图，尽管不同视图见的差异有时很大，但是其中必然保持着某种联系，存在着一致性。
因此，多视图方法有两个方面的实际意义:
1）利于思考(因为分而治之的思维方式)。
2）便于交流(因为在一定程度 上分离了涉众关注点)。
对架构设计方法而言，区分阶段和视图的概念是非常重要和必要的。逻辑架构和物理架构是架构设计同一阶段中须要同时考虑的两个方面——即二者是两个视图，而非两个阶段。
5视图方法
5视图方法包含如下几个视图:
■逻辑视图
■开发视图
■运行视图
■物理视图
■数据视图
5个视图各有其“思维立足点”，分别是:
■职责划分(逻辑视图)
■程序单元组织(开发视图)
■控制流组织(运行视图)
■物理节点安排(物理视图)
■持久化设计(数据视图)
逻辑架构
划分子系统、定义接口....这些典型工作都属于逻辑架构设计的范畴。
就划分子系统这个架构师必做的工作而言，其实践策略可归纳为3种:分层的细化、分区的引入、机制的提取。
下面是分层的细化、分区的引入、机制的提取这3种策略背后的4个通用设计原则:
■职责不同的单元划归不同子系统。
■通用性不同的单元划归不同子系统。
■需要不同开发技能的单元划归不同子系统。
■兼顾工作量的相对均衡，进一步切分太大的子系统。
对于接口设计，遵循协作决定接口，直接设计接口是很多“面向接口的”架构依然拙劣的原因之一。规划好接口定义，才能更好的使其他系统进行调用，避免出现严重问题
