《一线架构师实践指南》之细化架构
《一线架构师实践指南》第三部分讲述的是ADMEMS方法体系中三个阶段的细化架构阶段（Refined Architecture）。原文对于细化架构的的初始简介是针对于概念架构而言的，他们分别是两个层次的行为，前者属于“概念层”的解决方案，而后者属于“规约层”的解决方案。这就注定了他们所针对的不同性。
1细化架构
细化架构，顾名思义就是将架构进行细化。在架构设计时，我们需要通过架构视图作为分而治之的手段，使架构师可以分别专注于架构的不同方面、相对独立分析和设计不同子问题。细化架构就为我们提供了一个很好的解决方案。虽然如此，那为什么不能在概念架构设计之初就进行这种细化呢？这是我刚刚学习细化架构所产生的问题。
1.1概念架构和细化架构
虽然说在概念架构实行之初，我们就很尽量的去完善我们对于架构的估量，然是，就开发而言，概念架构是很难去支持并行开发的，这就给我们在团队开发的时候造成了一定的困难，因为此时我们团队中的某些成员的工作可能会发生复杂的交叉，以至于工作不能更好的进行下去，因此，要想使得团队中开发人员相对独立的进行工作，就必须给其提供可以进行指导和限制作用的更明确的“规约”级设置。所以说，细化架构是架构师工作中必不可少的一部分。
下面我们可以借用原文的两幅图来对概念架构和细化架构进行比较。
我们可以看到，左边的一幅图是概念架构的分层结果，右边一幅图是细化架构的层次划分。从这里，加上文中的讲解，我们可以做出以下的归类。
1.1.1概念架构与细化架构的差别
（1）接口。在细化架构中，接口占据非常核心的地位，而概念架构并不关心明确的接口定义（只有抽象的组件和抽象的交互机制）。
（2）子系统。细化架构重视通过子系统和模块来分割整个系统，并且子系统往往有明确的接口；而概念架构中只有抽象的组件，这些组件没有接口，只有职责，一般是处理组件、数据组件或连接组件中的一种。当然，概念架构中也有“大组件分解成小组件”的设计决策，但并非子系统的含义。
（3）交互机制。细化架构中的交互机制应是“实在”的，如基于接口编程、消息机制或远程方法调用等；而概念架构中的交互机制是“概念化”的，例如“A层使用B层的服务”。这里的“使用”在细化架构中可能是基于接口编程、消息机制或远程方法调用等其中的一种。
当然，概念架构和细化架构都满足软件架构的定义——无论是“架构=组件+交互”，还是“架构=重要决策集”。
1.2细化架构的实现方法
书中在介绍细化架构之初，从各种细化架构的发展历程来将细化架构进行介绍，末了着重介绍5视图方法。5视图方法包含以下几个视图：
· 逻辑视图
· 开发视图
· 运行视图
· 物理视图
· 数据视图
这五种视图又各自有各自的立足点，书中将其称之为“思维立足点”：
· 职责划分（逻辑视图）
· 程序单元组织（开发视图）
· 控制流组织（运行视图）
· 物理节点安排（物理视图）
· 持久化设计（数据视图）
五视图的基本架构如下：
1.2.1 5视图的设计方法
在传统的架构设计中，我们会采用2视图的方法进行设计，这也是我们在平时学习中所运用较多的看待问题的方法。相对来说，5视图方法适合更大型的软件，因为它能够更全面地覆盖了架构设计的各个方面。通过对细化架构的了解运用，可以使架构师站在5个不同的“思维立足点”、分而治之、分别设计，具体方法描述如下：
逻辑视图设计是面向对象或结构化，目标是设计职责划分和职责间协作，例如分模块、分层、划分垂直功能子系统，为模块、层、子系统定义接口。开发视图设计是面向文件，目标是设计程序单元和程序单元组织，例如，开发语言选型、应用程序框架选择、编译依赖关系等。运行视图设计是面向控制流，目标是设计控制流和控制流组织，例如，多进程技术、多线程技术、中断服务程序等物理视图设计是面向节点，目标是设计物理节点和物理节点拓扑，例如，PC机、服务器、单片机的机型与拓扑连接等数据视图设计是面向表或文件，目标是设计数据存储格式和持久化设计，例如，关系数据库、实时数据库、文件等。
具体的5视图设计方法是针对具体的架构而言的，他在每个架构（也就是每个视图中），都会有自己专门的技术关注点，也正是这样，才能将大粒度的概念划分成为细小的方法，而看似复杂的5视图，其实也在特定的角度体现着“组件 + 交互”的架构定义。
未完待续·········
参考资料：
1. 温昱. 一线架构师实践指南[M]. 北京:电子工业出版社, 2009.
2. 皮皮杂谈. 架构设计之细化架构设计方法 . 2019.
