架构设计30-架构模式02-分层架构模式

简介: 架构设计30-架构模式02-分层架构模式

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

介绍

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

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

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

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

讲解

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

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

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

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

模式描述

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

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

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

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

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

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

特点

  • 开发

  • 过程管理(康威定律)

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

  • 可测试性

分层模式太多变体,无法评估。

  • 可扩展性

分层模式太多变体,无法评估。

  • 运维

  • 可伸缩

分层模式太多变体,无法评估。

  • 部署难易

分层模式太多变体,无法评估。

  • 维护难易

分层模式太多变体,无法评估。

  • 性能

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

总结:

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

参考

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

目录
相关文章
|
7天前
|
存储 消息中间件 JSON
|
30天前
|
运维 Java Docker
业务系统架构实践问题之在某些情况下,将能力代码和业务逻辑严格分层可能是一个挑战问题如何解决
业务系统架构实践问题之在某些情况下,将能力代码和业务逻辑严格分层可能是一个挑战问题如何解决
|
30天前
|
存储 搜索推荐 API
业务系统架构实践问题之分层架构中的四层定位是什么
业务系统架构实践问题之分层架构中的四层定位是什么
|
30天前
|
缓存 项目管理
项目管理定义问题之DDD架构的分层架构中基础层作用是什么
项目管理定义问题之DDD架构的分层架构中基础层作用是什么
|
1月前
|
存储 消息中间件 Kafka
细说数据仓库分层架构
【7月更文挑战第20天】数据仓库分层架构包括缓冲层、操作数据层、明细数据层、汇总数据层和数据集市层。
|
20天前
|
运维 Kubernetes Cloud Native
云原生技术浪潮下的微服务架构演进
在数字化转型的风潮中,云原生技术以其灵活性、可扩展性和弹性成为企业IT战略的核心。本文深入探讨了微服务架构如何借助云原生环境进行优化,并分析了容器化、服务网格等技术如何助力微服务更好地适应云原生生态。通过案例分析,我们揭示了微服务在现代云平台上的实践挑战与解决策略,同时对未来的技术趋势进行了预测。
44 0
|
3天前
|
监控 负载均衡 API
从单体到微服务:架构转型之道
【8月更文挑战第17天】从单体架构到微服务架构的转型是一项复杂而系统的工程,需要综合考虑技术、团队、文化等多个方面的因素。通过合理的规划和实施策略,可以克服转型过程中的挑战,实现系统架构的升级和优化。微服务架构以其高度的模块化、可扩展性和灵活性,为业务的持续发展和创新提供了坚实的技术保障。
|
12天前
|
Cloud Native 云计算 微服务
云原生时代:企业分布式应用架构的惊人蜕变,从SOA到微服务的大逃亡!
【8月更文挑战第8天】在云计算与容器技术推动下,企业分布式应用架构正经历从SOA到微服务再到云原生的深刻变革。SOA强调服务重用与组合,通过标准化接口实现服务解耦;微服务以细粒度划分服务,增强系统灵活性;云原生架构借助容器化与自动化技术简化部署与管理。每一步演进都为企业带来新的技术挑战与机遇。
50 6
|
10天前
|
设计模式 监控 API
探索微服务架构中的API网关模式
在微服务的宇宙里,API网关是连接星辰的桥梁。它不仅管理着服务间的通信流量,还肩负着保护、增强和监控微服务集群的重任。本文将带你走进API网关的世界,了解其如何成为微服务架构中不可或缺的一环,以及它在实际应用中扮演的角色和面临的挑战。
|
18天前
|
运维 监控 负载均衡
探索微服务架构中的API网关
在现代软件开发中,微服务架构已成为设计灵活、可扩展系统的首选方法。本文将深入探讨API网关的核心作用,包括它如何简化客户端与微服务之间的交互,提供请求路由、负载均衡、认证、限流及监控等关键功能。我们将通过实际案例分析,揭示API网关在提升系统性能、增强安全性和提高开发效率方面的重要性。

热门文章

最新文章