soc的原则

2.1  子系统和框架在架构设计中的地位

2.1.1  关注点分离之道

好的架构设计必须把变化点错落有致地封装到软件系统的不同部分，为此，必须进行关注点分离。Ivar Jacobson在《AOSD中文版》中写道：

好的架构必须使每个关注点相互分离，也就是说系统中的一部分发生了改变，不会影响其他部分。即使需要改变，也能够清晰地识别出哪些部分需要改变。如果需要扩展架构，影响将会最小化。已经可以工作的每个部分都将继续工作。

那么，如何通过关注点分离来达到“系统中的一部分发生了改变，不会影响其他部分”的目标呢？

首先，可以通过职责划分来分离关注点。面向对象设计的关键所在，就是职责的识别和分配。每个功能的完成，都是通过一系列职责组成的“协作链条”完成的；当不同职责被合理分离之后，为了实现新的功能只需构造新的“协作链条”，而需求变更也往往只会影响到少数职责的定义和实现。无论是对象、模块，还是子系统，它们所承担的职责都应该具有高内聚性，否则对象之间的松耦合性就失去了基础，成为空谈。架构模式和设计模式为特定上下文中重复出现的问题提供了通用的职责划分方案。

其次，可以利用软件系统各部分的通用性的不同进行关注点分离。不同的通用程度意味着变化的可能性不同，将通用性不同的部分分离有利于通用部分的重用，也便于对专用部分进行修改。打个比方，一座高楼大厦要想稳固，必须考虑不同部分的热胀冷缩系数的差异，将不同“膨胀比”的部分硬连在一起容易引起“开裂”，这个比喻很好地说明了“稳固的架构”的含义。广为人知的框架技术可以用于分离通用部分，而元模型驱动方法是另一种分离通用性部分的技术。

另外，还可以先考虑大粒度的子系统，而暂时忽略子系统是如何通过更小粒度的模块和类组成的。在实际中，软件架构师常常将系统划分为一组子系统，并为子系统定义明确的接口，其中的细节将随其后的开发工作慢慢展开。这样做可以避免陷入过多的细节当中，所谓“忘却是一种能力”，就是指架构师必须有在更高层面思考的能力（第19章将以继承为例说明如何突破OOP思维的限制）。

图2-1总结了上述的架构设计关注点分离原理。可以说，根据职责分离关注点、根据通用性分离关注点、根据不同粒度级别分离关注点是3种位于不同“维度”的思维方式，所以在实际工作中必须综合运用这些手段。

图2-1  架构设计关注点分离原理