[架构]一线架构师实践指南----Refined Architecture阶段阅读笔记

1.什么是Refined Architecture(细化架构)

　　Refined Architecture(细化架构)是相对于Conceptual Architecture(概念架构)而言的，分别是架构的两个层次，分别对应“概念级”解决方案和“规约级”解决方案 。

　　架构领域习惯用建筑设计的多视图方式与软件架构设计的多视图方式做类比，如下图：

　　

 

 

 　　分别从功能与布线两种角度，这两种视图来对房间进行设计。而功能视图主要注重：装饰、家电家具、灯等物品；而布线视图主要注重：电话线、网线、插座等等。

　　除此之外还可以发现，功能视图和布线视图是互相影响的。如有功能图有些家具器具无法布线，而没有布线或者说没有插座的地方无法使用家电等等，这种软件架构设计的多视图思想与“兼顾多个视图设计之间的一致性”的要求是神似的。这种多视图的方法摆脱了在一张图内画来画去的困境。

2.实际意义

　　从医生治病的角度来看，外科医生通常研究的是骨骼图以及肌肉图。而内科医生主要研究的是内脏以及内部，虽然这些视图不同，但都有内在的相关性：共同描述了人体的结构。

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

• 便于思考：从分而治之的角度思考
• 便于交流：在一定程度上分离了涉众关注点

3.业界现状

　　OO方法太过流行，以至于行业内许多人都认为许多技术是OO的分支，但仅仅OO技术不能涵盖架构的全部内容，对一名架构师来说仅具有OO技能是不够的。

　　除此之外，很多人会误将“视图”当做“阶段”。如图：

　　

 

 

 　　左边的观点认为概念架构----逻辑架构----物理架构是三个不同的层次，然而这种观点不完全正确，因为逻辑架构与物理架构是统一阶段的两个视图，在同一水平层面上。

　　因而这几个不是垂直水平的关系，而是一个立体层次的关系。

4.视图

　　4.1 RUP 4+1 视图

　　在软件架构的发展史上，4+1视图具有重大贡献。

　　

 

 

 　　其有几个重大特点：

• 重视OO方法
• Use Case驱动
• 强调模型的重要性

　　而实践中应该注意：

• OO可以指导逻辑架构视图的设计，但OO对物理视图等设计的指导很弱。
• 用例不是架构设计本身的工作。4+1视图中的4是架构设计，+1是驱动因素。
• 如果一个模型建立没有启发思维，建立后从不修改，需要考虑是否“过度建模” 。

　　具体的多视图方法种类繁多：

• SEI的3视图法。涉及视图为：模型视图、组件-连接器视图、分配视图。
• 西门子的4视图法。涉及视图为：概念视图、模块视图、代码视图、执行视图。
• RUP的4+1视图法。涉及视图为：用例视图、逻辑视图、开发视图、进程视图、物理视图。
• 其他····

　　如下图5视图法：

　　

 

 

5.逻辑架构

　　划分子系统策略可归纳为 3 种： 1.分层的细化 2.分区的引入 3.机制的提取

　　基于三层架构的分层细化的一种方式：

　　

 

 

 　　迭代开发盛行，而真正意义上的迭代开发，必须解决一个困扰，在层的概念上，以“深度优先”的方式完成一个个具体的功能就是不可能的。而为了支持迭代开发，逻辑架构中必须引入分区的概念。分区是一种单位，它位于某个层的内部，粒度比层小。一旦对某个层进行了分区设计，“深度优先”的迭代开发就非常自然了。

　　Grady Booch在他的著作中指出：

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

　　什么是机制呢？

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

　　下图是协作：

　　

　　下图是机制：

　　

 

 

　　分层的细化、分区的引入、机制的提取这三个手段不是相互替代的关系，而是相辅相成的关系。

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