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