一线架构师实践指南 阅读笔记03

Refined Architecture 阶段（细化架构阶段）

如果一个项目的系统架构（包括理论基础）尚未确定，就不应该进行此系统的全面开发。
                                                            ——Barry Boehm，《Engineering Context》

从概念架构到细化架构，先设计概念架构，构思关键问题的解决策略；再进行细化架构的设计，以保证为开发提供足够的指导和限制。简单理解，细化架构就是分割，将大问题化成小问题，将概念架构中的设计进行实现，概念架构难以支持并行开发，所以要有细化架构的过程，将概念具体化，用代码进行实现，细化架构和概念架构之间的典型差异：

	细化架构	概念架构
接口	核心地位	不关心明确的接口定义，只有抽象的组件和抽象的交互机制
子系统	通过子系统和模块来分割整个系统，并且子系统往往有明确的接口	只有抽象的组件，这些组件没有接口，只有职责，一般是处理组件、数据组件或连接组件中的一种。（有大组件分解成小组件的设计决策，非子系统的含义）
交互机制	“实在”的交互机制，如基于接口编程、消息机制或远程方法调用	概念化的

 

方案 = “项目 + 需求 + 架构”的总览 ≠ 架构的全部

 

 

 

架构设计应该具有“分而治之”的思想，而不是一概而论，在细化架构设计的思路方面，有多视图方法。

多视图方法有两方面的实际意义：

1. 利于思考（因为分而治之的思维方式）
2. 便于交流（因为在一定程度上分离了涉众关注点）

对于架构设计方法而言，区分阶段和视图的概念是非常重要和必要的。

A的观点——三个架构是3个不同的层次，其实逻辑架构和物理架构是架构设计同一阶段中须要同时考虑的方各方面，即二者是两个视图，而非两个阶段。

5视图方法

核心思想：从不同角度，规划“分割”与“交互”。

5视图方法包括逻辑视图、开发视图、运行视图、物理视图、数据视图。

 

逻辑架构

划分子系统

划分子系统的策略：

1. 分层的细化
2. 分区的引入
3. 机制的提取

（1）分层（Layer）的细化

（2）分区的引入

分区是一种单元，它位于某个层的内部，其粒度比层要小。如图：

将每一层次进行细化分，换分成粒度更小的分区，在“分而治之”的前提下，再次“分而治之”。

（3）机制的提取

机制才是设计的灵魂所在……否则我们就将不得不面对一群无法相互协作的对象，他们相互推操着做自己的事情而毫不关心其他对象。

软件中的机制，是指预先定义好的、能够完成预期目标的、基于抽象角色的写作方式。机制不仅包含了协作关系，同时也包含了协作流程。

协作可以定义为“多个对象为完成某种目标而进行的交互”，“协作和机制”的区别：

    基于接口（和抽象类）的协作是机制，基于具体类的协作则算不上机制。

在这块儿呢，我理解为将每个协作封装成接口，通过接口调用，就是机制。

 

架构设计的分割示意图：

子系统划分的4个重要原则：

 

 

分是手段，合是目的。协作决定接口。

 

划分子系统，设计逻辑架构过程：

1. 根据当前理解切分（从概念架构开始）

2. 找到某功能的参与单元（若无，返回1）

3. 让他们协作完成功能

4. 质疑并推进设计的深入

物理架构、运行架构、开发架构

 

物理架构设计的任务

1. 硬件选择与物理拓扑
2. 软件到硬件的映射关系
3. 方案的优化

运行架构的工作内容

1. 确定引入那些控制流
2. 确定每条控制流的任务
3. 处理相关问题，控制流的创建、销毁、通信机制等
4. 进一步考虑，控制流之间的同步关系，若有资源争用还要引入加锁机制

 

控制流图是关键。

实现控制流的3种常见手段：进程、线程、中断服务程序。

 

开发架构设计的工作内容

1. 将“逻辑职责”映射为“程序单元”：要自主编写的源程序；可重用的库、框架；其它方式（shell脚本、平台支持下的配置文件）
2. 开发技术选型：开发语言；开发工具

3. “程序单元”间关系：project划分（可选），project目录结构；编译依赖关系。

 

 

 本文素材来源：《一线架构师实践指南》--温昱