《一线架构师实践指南》- 细化架构故事，Refined Architecture

回顾：

重大需求塑造概念架构（功能、质量、约束）
概念架构是一个“架构设计阶段”，针对重大需求，特色需求，高风险需求
不能只考虑“功能需求”，沦入理想化架构
目标-场景-决策 让架构师理性应对非功能需求
质疑驱动架构设计，非功能需求也会引起架构设计的调整

细化架构

细化架构和概念架构的差异：
接口： 细化架构中，接口占据非常核心的地位，概念架构不关心明确的接口定义，只有抽象的组件和交互机制；
子系统： 细化架构重视通过子系统和模块来分割整个系统，并且子系统往往有明确的接口；而概念架构中只有抽象的组件，没有接口，只有职责；
交互机制： 细化架构中的交互机制应该是“实在”的，该奶奶架构的交互机制是“概念化”的。

Refined Architecture

一种优秀的多视图方法，应该能够比较完善的覆盖架构设计的各项工作内容，且将每项工作内容明确的、有理有据的、一目了然的归到不同的架构视图中去。

RUP 4+1 视图

用例视图、逻辑视图、开发视图、进程视图、物理视图
特点：
重视OO方法
Use Case驱动
强调模型的重要性

SEI 3 视图 – 《软件架构实践》

模块视图。 元素是模块，它们是实现单元。
组件-连接器视图。 元素是运行时组件，连接器。
分配视图。分配结构展示了软件元素和创建并执行软件的一个或多个外部环境中元素之间的关系。

五视图方法

逻辑视图 – 职责划分
开发视图 – 程序单元组织
运行视图 – 控制流组织
物理视图 – 物理节点安排
数据视图 – 持久化设计

典型详图

逻辑架构

划分子系统

实践策略分为三类：分层的细化、分区的引入、机制的提取
《代码之道》：
“广度优先极端情况下意味着对每一个功能进行定义，然后对每一个功能进行设计，接着对每个功能进行编码，最后才对所有的功能进行一起测试。而深度优先极端情况下意味着每个功能完整的进行定义、设计、编码和测试，而只有当这个功能完成后，才能作做下一个功能，当然两个极端都是不好的，但是深度优先要好得多，对于大部分团队来说，应该做一个高级的广度设计，然后马上转到深度优先的底层设计和实现上去”。

引入分区，分区是一种单元，位于某一个层的内部，粒度比层小，一旦架构师对每个层进行分区的设计，“深度优先”的迭代开发就非常自然。

机制：软件系统中的机制是预先定义好的、能够完成预期目标的、基于抽象角色的协作方式。机制不仅包含了协作关系，同时也包含的协作流程。
基于接口（和抽象类）的协作是机制，基于具体类的协作则算不上机制。

四个原则：

1. 职责不同的单元划归不同的子系统
2. 通用性不同的单元划归到不同的子系统
3. 需要不同开发技能的单元划归到不同的子系统
4. 兼顾工作量的相对均衡，进一步切分太大的子系统

协作决定接口

模块化设计的原因是，分是手段，合是目的。不能合在一起支持更高层次功能的模块，又有何用？
接口设计依赖协作

质疑驱动逻辑架构设计

1. 质疑驱动
2. 结构设计和行为设计分离
   过程：
   第一步：根据当前理解切分（运用分层的细化，分区的引入，机制的提取来划分子系统）
   第二步：找到某功能的参与单元
   第三步：协作完成功能
   第四步：质疑并推进设计的深入

十条经验

1. 划分子系统：分层的细化
2. 划分子系统：分区的引入
3. 划分子系统：机制的提取
4. 接口的定义：协作决定接口
5. 选用序列图：杜绝协作图
6. 包-接口图：从结构到行为的桥
7. 灰盒包图：描述关键子系统
8. 循序渐进的螺旋思维
9. 设计模式：包内结构
10. 设计模式：包间协作

《面向对象软件工程》