漫谈分层架构：为什么要进行架构分层？

本文主要是介绍漫谈分层架构：为什么要进行架构分层？，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

• 高内聚：分层的设计可以简化系统设计，让不同的层专注做某一模块的事
• 低耦合：层与层之间通过接口或API来交互，依赖方不用知道被依赖方的细节
• 复用：分层之后可以做到很高的复用
• 扩展性：分层架构可以让我们更容易做横向扩展

如果系统没有分层，当业务规模增加或流量增大时我们只能针对整体系统来做扩展。分层之后可以很方便的把一些模块抽离出来，独立成一个系统。

优点：关注前后端分离

缺点：模型层分层太粗，融合了数据处理、业务处理等所有的功能。核心的复杂业务逻辑都放到模型层，导致模型层很乱

适应场景：后端业务逻辑简单的服务，比如接口直接提供对数据库增删改查

定义：

1. 表现层：controller
2. 逻辑层：service
3. 数据访问层：dao

优点：逻辑与数据层分离

缺点：模型层分层比较粗，核心的复杂业务逻辑都放到模型层，导致模型层很乱

适应场景：后端业务逻辑简单的服务，比如接口直接提供对数据库增删改查

架构来源：参照参照阿里发布的《阿里巴巴 Java 开发手册 v1.4.0（详尽版）》，将原先的三层架构细化而来

特点：添加了Manager 通用业务处理层。

这一层有两个作用，一、可以将原先 Service 层的一些通用能力下沉到这一层，比如与缓存和存储交互策略，中间件的接入；二、也可以在这一层封装对第三方接口的调用，比如调用支付服务，调用审核服务等RPC接口。

优点：相比于三层方式，添加了通用处理层对接外部平台。 上下游对接划分的比较清晰

缺点：核心业务逻辑层没有划分

适应场景：业务逻辑不复杂的常用业务

1. 数据、缓存等都视为基础层， 可以被所有层调用
2. 抽离了领域层，负责核心业务逻辑处理，领域层调用外部依赖全部通过接口，以保证领域层的100%单测覆盖率
3. 应用层聚合多个领域层的能力，只做功能的组合、转发，不负责具体业务逻辑

优点：相比于三层方式，更关注领域服务，即业务核心逻辑的划分、收敛

缺点：分层复杂， 如果业务逻辑简单没有必要

适应场景：业务复杂的业务

DDD四层架构也基于传统三层架构的，不同点有以下几方面：

1. 关注点不一样：三层架构关注请求调用顺序；DDD架构关注领域服务。
2. 横向划分方式不一样：三层架构主要关注纵向划分，对横向划分没有约定；DDD架构更关注纵向，即：多个领域层之间划分及交互方式。
3. 对资源的定位不一样：三层架构把所有依赖的数据都放到数据访问层；DDD架构只将领域强关联的数据放到Repository中，其他比如API层缓存、文件等都当成基础服务来处理。

整洁架构和六边形架构都是DDD架构的一种方式，只不过是视角不同。

特点：整洁架构的层就像洋葱片一样，它体现了分层的设计思想

整洁架构最主要的原则是依赖原则，它定义了各层的依赖关系，越往里依赖越低，代码级别越高，越是核心能力。外圆代码依赖只能指向内圆，内圆不需要知道外圆的任何情况。

六边形架构又名“端口适配器架构”。追溯微服务架构的渊源，一般都会涉及到六边形架构。

六边形架构的核心理念是：应用是通过端口与外部进行交互的。我想这也是微服务架构下API网关盛行的主要原因吧。

也就是说，在下图的六边形架构中，红圈内的核心业务逻辑（应用程序和领域模型）与外部资源（包括APP、Web应用以及数据库资源等）完全隔离，仅通过适配器进行交互。它解决了业务逻辑与用户界面的代码交错问题，很好地实现了前后端分离。六边形架构各层的依赖关系与整洁架构一样，都是由外向内依赖。

本文汇总了传统MVC架构、后端三层架构、阿里分层架构、DDD架构以及基于DDD架构的整洁架构和六边形架构。从前往后越来越复杂，其他也对应着软件工程的越来越复杂，架构模式也变的越来越复杂。软件架构领域没有一招鲜吃遍天的功法，针对的不同的业务场景采用不同的架构，并且随着业务的发展，不断调整架构以适应业务的发展，以变（架构、技术组件、重构等）应不变（业务发展、用户体验、稳定性等）才是一个合格的软件工程师应追求的境界。

原文链接：https://juejin.cn/post/6907828643062513671

如果觉得本文对你有帮助，可以关注一下我公众号，回复关键字【面试】即可得到一份Java核心知识点整理与一份面试大礼包！另有更多技术干货文章以及相关资料共享，大家一起学习进步！

这篇关于漫谈分层架构：为什么要进行架构分层？的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！