如果系统没有分层,当业务规模增加或流量增大时我们只能针对整体系统来做扩展。分层之后可以很方便的把一些模块抽离出来,独立成一个系统。
优点:关注前后端分离
缺点:模型层分层太粗,融合了数据处理、业务处理等所有的功能。核心的复杂业务逻辑都放到模型层,导致模型层很乱
适应场景:后端业务逻辑简单的服务,比如接口直接提供对数据库增删改查
定义:
优点:逻辑与数据层分离
缺点:模型层分层比较粗,核心的复杂业务逻辑都放到模型层,导致模型层很乱
适应场景:后端业务逻辑简单的服务,比如接口直接提供对数据库增删改查
架构来源:参照参照阿里发布的《阿里巴巴 JAVA 开发手册 v1.4.0(详尽版)》,将原先的三层架构细化而来
特点:添加了Manager 通用业务处理层。
这一层有两个作用,一、可以将原先 Service 层的一些通用能力下沉到这一层,比如与缓存和存储交互策略,中间件的接入;二、也可以在这一层封装对第三方接口的调用,比如调用支付服务,调用审核服务等RPC接口。
优点:相比于三层方式,添加了通用处理层对接外部平台。 上下游对接划分的比较清晰
缺点:核心业务逻辑层没有划分
适应场景:业务逻辑不复杂的常用业务
优点:相比于三层方式,更关注领域服务,即业务核心逻辑的划分、收敛
缺点:分层复杂, 如果业务逻辑简单没有必要
适应场景:业务复杂的业务
DDD四层架构也基于传统三层架构的,不同点有以下几方面:
整洁架构和六边形架构都是DDD架构的一种方式,只不过是视角不同。
特点:整洁架构的层就像洋葱片一样,它体现了分层的设计思想
整洁架构最主要的原则是依赖原则,它定义了各层的依赖关系,越往里依赖越低,代码级别越高,越是核心能力。外圆代码依赖只能指向内圆,内圆不需要知道外圆的任何情况。
六边形架构又名“端口适配器架构”。追溯微服务架构的渊源,一般都会涉及到六边形架构。
六边形架构的核心理念是:应用是通过端口与外部进行交互的。我想这也是微服务架构下API网关盛行的主要原因吧。
也就是说,在下图的六边形架构中,红圈内的核心业务逻辑(应用程序和领域模型)与外部资源(包括App、Web应用以及数据库资源等)完全隔离,仅通过适配器进行交互。它解决了业务逻辑与用户界面的代码交错问题,很好地实现了前后端分离。六边形架构各层的依赖关系与整洁架构一样,都是由外向内依赖。
本文汇总了传统MVC架构、后端三层架构、阿里分层架构、DDD架构以及基于DDD架构的整洁架构和六边形架构。从前往后越来越复杂,其他也对应着软件工程的越来越复杂,架构模式也变的越来越复杂。软件架构领域没有一招鲜吃遍天的功法,针对的不同的业务场景采用不同的架构,并且随着业务的发展,不断调整架构以适应业务的发展,以变(架构、技术组件、重构等)应不变(业务发展、用户体验、稳定性等)才是一个合格的软件工程师应追求的境界。
原文链接:https://juejin.cn/post/6907828643062513671
如果觉得本文对你有帮助,可以转发关注支持一下