从共享分层结构的视角优化架构

下面我们再从第三个方面审视架构设计，关注点在模块的缠绕和分散。所谓缠绕，指的

是一个模块是不是包含了多个模块不同的实现。所谓分散，一个模块的实现分散在多个不同

的模块中。解决这些缠绕和分散问题，需要使用分层结构来解决。

1，层模式的问题与机会

在模块分割以后，就会发现有些功能块或者某些功能是共享的或者缠绕的，我们需要把

这些模块或者功能提取出来，分成若干层次，这就是层模式。层模式是构造弹性架构的基础，

好的架构几乎都是在层这个模式基础上建立起来的。分层不是目的，分层必须把分离性与易

变性、灵活性结合起来，这也是设计层模式有挑战性的问题，也是最近几年最吸引人的研究

领域之一。合理的分层也是架构师很大的一部分需要仔细设计的工作。

1）问题：

如果系统的许多部分高度的耦合，源代码的变化将波及整个系统。

如果应用逻辑与用户接口捆绑在一起，这些应用逻辑在其它不同的接口上无法重

用，也无法分布到另一个处理节点上。

如果潜在的通用技术服务或业务逻辑，与更具体的应用逻辑捆绑在一起，这些通用

技术服务或者业务逻辑无法被重用，或者分布到其它的节点，或者被不同的实现简

单的替换。

在系统的不同部分高度的耦合的情况下，难以对不同开发者清晰界定各自的工作界

限。

如果高度耦合混合在系统的各个方面，则改进应用程序的功能，扩展系统，以及使

用新技术进行升级往往是艰苦和代价高昂的。

2）解决方案：

层模式（Layers pattern）的基本思想很简单。

根据分离系统的多个具有清晰、内聚职责的设计原则，把系统大尺度的逻辑结构组

织到不同的层中，每一层都具有独立和相关的职责，使得较低的层为低级和通用的

服务，较高的层更多的为特定应用。

从较高的层到较低的层进行协作和耦合，避免从底层到高层的耦合。

层是一个大尺度的元素，通常由一些包或者子系统组装而成。层模式与逻辑架构相关，

也就是说，它描述了设计元素概念上的组织，但不是它物理上的包或者部署。层为逻辑架构

定义了一个 N 层模型，称之为分层架构（Layers Architecture），它作为模式得到了极为广泛

的应用和引述。作为分层架构的模式，我们必须提到框架（framework）的概念，一般来说框

架具有如下的特征：

是内聚的类和接口的集合，它们协作提供了一个逻辑子系统的核心和不变部分的服

务。

包含了某些特定的抽象类，它们定义了需要遵循的接口。

通常需要用户定义已经存在的框架类的子类，是客户得以扩展框架的服务。

所包含的抽象类可能同时包含抽象方法和实例方法。

遵循好莱坞原则：“别找我们，我们会找你。”就是用户定义得类将从预定义的类中

接受消息，这通常通过实现超类的抽象方法来实现。

3）示例：

信息系统一般分层逻辑架构如下图所示，图中包的宽度表示的是应用范围。

在具体架构设计的时候，可以建立比较详细的包图，但是，并不需要面面俱到。

架构视图的核心，是展示少数值得注意的元素，或者说选择一小组有意义的元素来传达

主要的思想。

2，层模式的设计原则

分层并不是具有固定模式的，比如三层架构或者七层架构，而是需要根据情况合理布局。

逻辑架构还可以包含更多的信息，用来描述层与层以及包与包之间值得注意的耦合关系。在

这里，可以用依赖关系表达耦合，但并不是确切的依赖关系，而仅仅是强调一般的依赖关系。

我们还需要注意到，分层主要解决共享和缠绕问题，而在设计时要考虑下层易变更问题，我

们需要仔细考虑变化点和变更方式，合理应用设计模式，实现封装变化的结构形式，以此寻

求架构解决方案，可以考虑如下一些策略。

1）协作：

在架构层面上，有两个设计上的决策：

什么是系统的重要部分？

它们是如何连接的？

在架构上，层模式对定义系统的重要部分给出了指导。象外观、控制器、观察者这些模

式，通常用于设计层与层、包与包之间的连接。

2）外观模式

GoF 的外观模式，定义了一个公共的外观对象综合子系统的服务。

外观不应该表示大量子系统的操作，更确切的说，外观更适合表示少量的高层操作、粗

粒度的服务。当外观呈现大量的底层操作的时候，会趋向于变得没有内聚力。外观模式为了

一组子系统提供一个一致的方式对外交互。这样就可以使客户和子系统绝缘，可以大大减少

客户处理对象的数目。本来一个类的修改可能会影响一大片代码，而加了外观类以后只需要

修改很少量的代码就可以了，使系统的高级维护成为可能。

3）通过观察者模式（Observer）实现向上协作

外观模式通常用于高层到底层的操作（底层提供外观，高层实现调用）。当需要上层对

底层的操作的时候，可以使用观察者模式。也就是上层响应底层的事件，但这个事件的执行

代码由上层提供。

4）在不同的层上模糊集合成员

一些元素必定只属于一个层，但有些元素却难以区分，特别是处在技术服务层和基础层

之间，或者领域层和业务基础设施层之间的元素。其实这些层之间只存在模糊的差异，所以，

“高层”、“底层”、“特殊”、“一般”这些术语是可以接受的。

开发组并不需要在限定的分类上做出决定，可以粗略的把一个元素归类到技术服务层或

者基础层，也可以称之为“基础设施层”，注意，对于层并没有十分确定的命名习惯和约定，

文献上各种命名上的矛盾是常见的，研究问题主要把握精髓，不要被这些表面的区别搞昏了

头。

5）层模式的优点：

层模式可以分离系统不同方面的考虑，这样就减少了系统的耦合和依赖，提高了内

聚性，增加了潜在的重用性，并且增加了系统设计上的清晰度。

封装和分解了相关的复杂性。

一些层的实现可以被新的实现替代，一般来说，技术服务层或者基础层这些比较低

层的层不能替换，而表示层、应用层和领域层可能进行替换。

较低的层包含了可重用的功能。

一些层可能是分布式的（主要是领域层和技术服务层）。

由于逻辑上划分比较清楚，有助于多个小组开发。