架构设计02--架构模式介绍02--分层架构模式

架构设计系列文章,请参见连接。

介绍

分层架构是最常见,也是最容易理解的架构模式。因为在现实生活中会遇到很多类似的例子与模型。例如在在装修的时候或者为一个金属器物刷油漆时最常见的方式就是刷多层。第一层刷石膏,第二层刷腻子,第三层刷乳胶漆。而且每一层都有它自己的意义。刷墙的时候石膏是为了保证墙面平整的,刷腻子是为了防止开裂的,刷乳胶漆是为了美观的。所以,在软件上我们也有类似的结构,去帮助我们管理每个层面上不同的问题。

再比如在人资、心理学方面大名鼎鼎的马斯洛需求层次理论就是讲人类的需求分为几个层面。马斯洛理论以层次的方式体现人们对社会、对个人的需求或者理解。也有学者提出人们对这些需求层次中的需求是同时存在的。再更近一步,佛洛伊德把我又更加细化的分为自我,本我,超我。


架构设计02--架构模式介绍02--分层架构模式_第1张图片
自我、本我、超我

从自我、本我、超我已经将分层模式进入到一种支配人们行动方式的层面了。所以,分层模式是生活、工作、学习中最常见也是做容易理解的模式。也从某方面说明分层模式并不一定非要是纵行分层,也不一定非要横向分层,可以事物跨层,或者洋葱层等等。

转回我们的软件行业。在《恰如其分的架构设计》中把架构设计中的模型也分了层次。分别是:领域模型,设计模型,代码模型。规定了从真实世界中的事物到技术实现层面的代码之间的关系。在下面具体介绍分层模式。

讲解

在OOA中我们经常会提到一个词:SOLID。这个词中第一个字母代表的意义就是单一职责。分层架构第一个目标是单一职责。在处理复杂问题的时候我们有几种办法:分解,知识,抽象。其实这些方法就是将一件事物去掉干扰,去掉非关键因素,提取和抽象出核心的过程。做这件事的意义在于每一个问题都有他自己要处理的核心问题,核心问题解决掉之后就能解决80%的问题。

第二个问题在于分层模式提供了高内聚低耦合的基础实现方法。分层架构第一步规定每层都是单一职责的。第二步就是规定每层不能深入到另外一层中。其实就是知识最少原则。这样让每层之间只能通过API(API是一个比较广泛的概念,可以是方法调用,可以是RPC,可以是事件)的方式去做交互。

分层架构为演进式架构提供了基础的支撑。分层可以提供内外部的隔离。也就是我们常说的微服务是以内部复杂度换为了外部复杂度。

在架构模式中一般不会简单的只是用某一种架构模式来搭建系统。而在架构模式中分层模式可谓是百搭。分层架构模式可以和任何架构模式组合搭配。

模式描述

首先,架构模式可以体现在不同的level上。就像上面提到的SOLID,最少知识原则最初都是体现在代码层面的设计上的。慢慢的会出现GoF的设计模式,以及本系列文章中介绍的架构模式。我们按照《恰如其分的架构设计》中对架构模型的分层,将架构分为:业务领域层,技术设计层,代码实现层。

架构模式可以在不同的层次上体现的方面,可以用分层模式举一个简单的例子。例如分层模式中的业务领域层可以中的分层模式可以是销售,制造,采购等。技术设计中可以是展示层,业务逻辑层,基础设施层,硬件层等。代码实现中可以是MVC分层,MVVC分层,MVVM分层等等。

第二,在分层模式中不止可以进行纵向分层,也可以进行横向分层,甚至还可以洋葱分层。具体的分层中还会有很多类似于反模式的形式出现,比如说跃层,比如说在一个大的分层中在分层。

针对这些分层方式作者举几个栗子。纵向分层的就像《Software Architecture Patterns》所说明的那样。分为:表示层、业务层、持久化层和数据库。


架构设计02--架构模式介绍02--分层架构模式_第2张图片
分层模式

在之后会介绍到的管道过滤器模式中就可以看做是一个横向的分层。在还有洋葱式的分层模型,最直接的就是针对领域进行分析时使用的六边形架构,clean架构。并且在现实的代码框架上也得到了了应用,例如Python中的web框架Django。


架构设计02--架构模式介绍02--分层架构模式_第3张图片
Claen架构

再举一个反模式的例子,这个图是我在平常使用的一个图。从图虫可以看到跨层,在细分的方式进行架构设计。


架构设计02--架构模式介绍02--分层架构模式_第4张图片
现实中的图

特点

  • 开发

  • 过程管理(康威定律)
    使用一人从顶到底的方式完成功能,或者使用按层隔离的方式都是可以实现系统的。不过这里面涉及到组织管理的模式。需要适应组织管理,或者组织管理适应方式进行。

  • 可测试性
    分层模式太多变体,无法评估。

  • 可扩展性
    分层模式太多变体,无法评估。

  • 运维

  • 可伸缩
    分层模式太多变体,无法评估。

  • 部署难易
    分层模式太多变体,无法评估。

  • 维护难易
    分层模式太多变体,无法评估。

  • 性能

因为分层模式通用性太强,没有办法去以一种方式评估他的性能。所以这里就粗略的说明一下。分层模式中如果使用方法调用的方式进行通信比使用线程间通信的方式高10倍,如果使用线程间通信的方式比使用进程间通信的方式高10倍,进程间通信的方式比主机之间通信的方式高10倍。

总结:

  1. 不要把架构模式就当做是架构模式,可以在任何的层面上使用架构模式。 架构模式给我们提供了原则,就会又回到那句话《规则对于智者来说是指导,对于愚者来说是遵从》。所以,请铭记原则,而不是这里所说到的各种各样的形式。
  2. 在设计模式中有几个模式可以提升到架构模式层面上使用。例如:门面(Facade)模式,策略模式等。门面模式给我们在架构设计中提供了一种思路,就是OpenStack中的服务集群的方式。
  3. 现在国内软件界在流行分布式系统的:大中台概念。所以,我们可以在分层模式中体现出架构模式的优点。具体怎样实施可以根据具体的项目确定。

参考

《恰如其分的软件架构.风险驱动的设计方法》14.6 分层风格
演进式架构设计
Software Architecture Patterns

你可能感兴趣的:(架构设计02--架构模式介绍02--分层架构模式)