021 | 回归架构本真:架构原则

前一篇文章已经聊了几种指导架构设计的思维方式,接着我想再说说架构设计的几个非常重要的原则。为什么要聊这个呢?从一方面来说,架构思维从面向过程,到现在的面向服务,以后也不知道还会出现什么新的思维方式。但无论是何种思维方式,都存在一些共通性的架构原则,可以指导我们如何设计出一个合适的架构。从另一方面来说,架构设计,不管是面向过程、面向对象、面向切面,还是面向服务,无一例外,主要都是在对复杂的系统进行分解。那么,相应地,就需要思考三个问题:分解为哪些?如何分解?分解到什么程度?相对应地,有三个重要原则可以分别为解答这三个问题提供指引。

关注点分离原则

关注点分离原则主要就是为了解决将复杂系统分解为哪些部分的问题,分解出来的部分就是关注点。过程、对象、切面、服务,只是分解的角度(也是关注点)不同而已。将复杂的问题根据不同的关注点分解为多个相对简单的问题,再对每个简单的问题进行分别处理,这就是关注点分离。分离之后,各个关注点相对独立,每个关注点的变化基本不会影响到其他的关注点,即使需要改变,改变的部分也很小。需要扩展时,影响也将会最小化。

关注点分离,最难的在于如何识别出有哪些关注点。要识别出有哪些关注点,需要将复杂系统不同的方方面面抽象成一个个具有清晰明确的边界的概念模型,或为“对象”,或为“组件”,或“切面”,或“服务”,以将复杂问题分解为一个个相对简单的问题。

从不同维度,可以有不同的分离方案。除了上面提到的面向过程、面向对象、面向切面、面向服务等思维角度之外,还有如下图所示的其他几种不同维度,该图引自《软件架构设计》一书中的【2.1.1 关注点分离之道】一节:

上图分别从功能职责、通用性、大小粒度的不同维度进行分离。从职责维度进行分离,就可以分为最经典的三层架构:展现层、业务层、数据层,相应的关注点就是:数据展示、数据加工、数据管理。如果是后端服务,数据层主要就是用数据库管理;如果是客户端应用,数据层还可以再分离为网络层和缓存层。从通用性维度来看,就可以分离出技术通用部分、领域通用部分、特定应用部分。一般,使用框架技术就可以用于分离各种不同的通用部分。从大小粒度的维度考虑,无非就是将复杂系统分离为各个子系统,再分离为不同模块,再细分到不同类。

在实际应用中,并不会只采用一种维度,而是多种维度综合考虑,不同部分采用不同维度的分离方案。比如,也许,整体上按职责分离为多层架构,然后,在某些层级根据大小粒度再进行分离,例如将业务层按照不同业务模块进行分离。另外,也会将不同的通用部分进行分离,例如可将技术通用部分的日志记录、领域通用部分的权限检查分别分离出来。

我们熟知的 MVC\MVP\MVVMRESTFulClean 等等架构风格,全都体现了不同维度的关注点分离。

高内聚低耦合原则

系统应该如何分解?或者说关注点应该如何分离?高内聚低耦合原则就可以为该问题提供设计指引。

内聚是指模块内部的功能和元素之间的紧密程度,而耦合则是指模块与模块之间的关联程度。

内聚可分为好多种:功能内聚、顺序内聚、通信内聚、过程内聚、时间内聚、逻辑内聚、偶然内聚。功能内聚是最强最好的内聚,模块内各元素共同协作完成一个单一的功能,这些元素紧密联系、缺一不可。顺序内聚则是指,模块中各个处理元素和同一个功能密切相关,而且这些处理必须顺序执行,通常前一个处理元素的输出是后一个处理元素的输入。顺序内聚的内聚度也比较高,但相比功能内聚,缺点就是可维护性相对差些。偶然内聚则是最弱的内聚,模块内的各元素之间没有任何联系,只是偶然地被凑到一起。

top Created with Sketch.