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

下面我们再从第三个方面审视架构设计,关注点在模块的缠绕和分散。所谓缠绕,指的
是一个模块是不是包含了多个模块不同的实现。所谓分散,一个模块的实现分散在多个不同
的模块中。解决这些缠绕和分散问题,需要使用分层结构来解决。
1,层模式的问题与机会
在模块分割以后,就会发现有些功能块或者某些功能是共享的或者缠绕的,我们需要把
这些模块或者功能提取出来,分成若干层次,这就是层模式。层模式是构造弹性架构的基础,
好的架构几乎都是在层这个模式基础上建立起来的。分层不是目的,分层必须把分离性与易
变性、灵活性结合起来,这也是设计层模式有挑战性的问题,也是最近几年最吸引人的研究
领域之一。合理的分层也是架构师很大的一部分需要仔细设计的工作。
1)问题:
如果系统的许多部分高度的耦合,源代码的变化将波及整个系统。
如果应用逻辑与用户接口捆绑在一起,这些应用逻辑在其它不同的接口上无法重
用,也无法分布到另一个处理节点上。
如果潜在的通用技术服务或业务逻辑,与更具体的应用逻辑捆绑在一起,这些通用
技术服务或者业务逻辑无法被重用,或者分布到其它的节点,或者被不同的实现简
单的替换。
在系统的不同部分高度的耦合的情况下,难以对不同开发者清晰界定各自的工作界
限。
如果高度耦合混合在系统的各个方面,则改进应用程序的功能,扩展系统,以及使
用新技术进行升级往往是艰苦和代价高昂的。
2)解决方案:
层模式(Layers pattern)的基本思想很简单。
根据分离系统的多个具有清晰、内聚职责的设计原则,把系统大尺度的逻辑结构组
织到不同的层中,每一层都具有独立和相关的职责,使得较低的层为低级和通用的
服务,较高的层更多的为特定应用。
从较高的层到较低的层进行协作和耦合,避免从底层到高层的耦合。
层是一个大尺度的元素,通常由一些包或者子系统组装而成。层模式与逻辑架构相关,
也就是说,它描述了设计元素概念上的组织,但不是它物理上的包或者部署。层为逻辑架构
定义了一个 N 层模型,称之为分层架构(Layers Architecture),它作为模式得到了极为广泛
的应用和引述。作为分层架构的模式,我们必须提到框架(framework)的概念,一般来说框
架具有如下的特征:
是内聚的类和接口的集合,它们协作提供了一个逻辑子系统的核心和不变部分的服
务。
包含了某些特定的抽象类,它们定义了需要遵循的接口。
通常需要用户定义已经存在的框架类的子类,是客户得以扩展框架的服务。
所包含的抽象类可能同时包含抽象方法和实例方法。
遵循好莱坞原则:“别找我们,我们会找你。”就是用户定义得类将从预定义的类中
接受消息,这通常通过实现超类的抽象方法来实现。
3)示例:
信息系统一般分层逻辑架构如下图所示,图中包的宽度表示的是应用范围。
在具体架构设计的时候,可以建立比较详细的包图,但是,并不需要面面俱到。
架构视图的核心,是展示少数值得注意的元素,或者说选择一小组有意义的元素来传达
主要的思想。
2,层模式的设计原则
分层并不是具有固定模式的,比如三层架构或者七层架构,而是需要根据情况合理布局。
逻辑架构还可以包含更多的信息,用来描述层与层以及包与包之间值得注意的耦合关系。在
这里,可以用依赖关系表达耦合,但并不是确切的依赖关系,而仅仅是强调一般的依赖关系。
我们还需要注意到,分层主要解决共享和缠绕问题,而在设计时要考虑下层易变更问题,我
们需要仔细考虑变化点和变更方式,合理应用设计模式,实现封装变化的结构形式,以此寻
求架构解决方案,可以考虑如下一些策略。
1)协作:
在架构层面上,有两个设计上的决策:
什么是系统的重要部分?
它们是如何连接的?
在架构上,层模式对定义系统的重要部分给出了指导。象外观、控制器、观察者这些模
式,通常用于设计层与层、包与包之间的连接。
2)外观模式
GoF 的外观模式,定义了一个公共的外观对象综合子系统的服务。
外观不应该表示大量子系统的操作,更确切的说,外观更适合表示少量的高层操作、粗
粒度的服务。当外观呈现大量的底层操作的时候,会趋向于变得没有内聚力。外观模式为了
一组子系统提供一个一致的方式对外交互。这样就可以使客户和子系统绝缘,可以大大减少
客户处理对象的数目。本来一个类的修改可能会影响一大片代码,而加了外观类以后只需要
修改很少量的代码就可以了,使系统的高级维护成为可能。
3)通过观察者模式(Observer)实现向上协作
外观模式通常用于高层到底层的操作(底层提供外观,高层实现调用)。当需要上层对
底层的操作的时候,可以使用观察者模式。也就是上层响应底层的事件,但这个事件的执行
代码由上层提供。
4)在不同的层上模糊集合成员
一些元素必定只属于一个层,但有些元素却难以区分,特别是处在技术服务层和基础层
之间,或者领域层和业务基础设施层之间的元素。其实这些层之间只存在模糊的差异,所以,
“高层”、“底层”、“特殊”、“一般”这些术语是可以接受的。
开发组并不需要在限定的分类上做出决定,可以粗略的把一个元素归类到技术服务层或
者基础层,也可以称之为“基础设施层”,注意,对于层并没有十分确定的命名习惯和约定,
文献上各种命名上的矛盾是常见的,研究问题主要把握精髓,不要被这些表面的区别搞昏了
头。
5)层模式的优点:
层模式可以分离系统不同方面的考虑,这样就减少了系统的耦合和依赖,提高了内
聚性,增加了潜在的重用性,并且增加了系统设计上的清晰度。
封装和分解了相关的复杂性。
一些层的实现可以被新的实现替代,一般来说,技术服务层或者基础层这些比较低
层的层不能替换,而表示层、应用层和领域层可能进行替换。
较低的层包含了可重用的功能。
一些层可能是分布式的(主要是领域层和技术服务层)。
由于逻辑上划分比较清楚,有助于多个小组开发。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值