总阅读量:次

⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 https://blog.csdn.net/hellozhxy/article/details/80224493 「hellozhxy」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

开发人员在使用Spring应用是非常擅长谈论依赖注入的好处。不幸的是，他们不是那么真的利用它的好处，如单一职责原则，分离关注原则。如果我们一起来看看大部分Spring的Web应用程序，常见的错误的设计如下：

1.领域模型对象用来存储应用的数据(当作DTO使用)，领域模型是贫血模型这样的反模式。

2.业务逻辑位于管理域对象数据的服务层中。

3.服务层每个实体有一个服务。

问题是这样很普遍，错误在哪里呢？

Spring的web应用程序之所以这样是因为他们做事物的方式一直都是这样做的，老习惯难改，特别是如果他们是高级开发人员或软件架构师，这些人捍卫这样做的论据之一是：我们的应用程序遵循关注分离的原则，因为它已经被分为若干层，每个层有自己的特定职责。

典型的SpringWeb应用程序具有以下层：

1**.Web层**负责处理用户输入，并返回正确的响应返回给用户。 web层与服务层通信。

2**.服务层**作为一个事务边界。它也负责授权和包含我们的应用程序的业务逻辑。服务层管理的域模型对象，并与其他服务和存储库层进行通信。

3**.存储库/数据访问层**负责与所使用的数据的存储进行通信。

分离关注(Soc)是分离计算机程序为不同的部分，每个部分有一个关注聚焦，一个典型的Spring Web应用在一定程度上遵循这一原则，但现实是，该应用程序有一个整体的服务层，它有太多的责任。更具体地，服务层有两个主要问题：

1.在服务层发现业务逻辑

业务逻辑被分散在各个服务层。如果我们需要检查一个业务规则是如何实现的，我们必须先找到它。这可能并不容易。此外，如果相同的业务规则需要在多个服务类，问题是，规则需要从一个服务到另一个简单地复制。这将导致维护的噩梦。

2.每个领域模型一个服务

这完全违反了单一职责原则，它被定义为如下：单一职责原则指出，每一个类都应该有一个责任，责任应该由类完全封装。其所有的服务应该狭义与责任相一致。(不应将原属于领域模型的行为方法等划放在服务中实现，对象不但有属性还有行为)

服务类有很多依赖，以及大量的循环依赖。更像网络紧密耦合和单片服务。这使得很难理解，维护和重用。这听起来有点苛刻，但一个Spring的web应用的服务层往往是最容易出问题的部分。幸运的是，所有的希望都不会丢失。

1. 我们必须将我们的应用程序的业务逻辑从服务层迁移到领域模型类中。

举个例子：假设我是一个服务类，你是一个域模型对象。如果我让你从屋顶上跳下来，你会喜欢我这样的决定吗？(跳下来会摔伤，自己没有脑子或被洗脑，变成僵尸，只听从执行，不思考自己的安全，这就是贫血模型的问题)

将业务逻辑从服务层迁移到域模型类有下面三个优势：

(1)我们的代码将以逻辑方式切割，服务层只要关注应用逻辑，而我们的领域模型关注业务逻辑。

(2)业务逻辑只存在一个地方，容易发现修改。

(3)服务层的源代码是清洁的，不包含任何复制粘贴代码

2. 将每个实体服务切割为单一目标的更小的服务。

比如，有一个单一服务类，提供对人员和用户账户的CRUD操作，我们应该将它分为两个独立的服务类：

第一个是对人员的提供CRUD操作

第二个是提供与用户账户相关的操作。

好处：每个服务类中有一个逻辑组职责。每个服务类的依赖较少，这意味着他们不再是紧耦合的源头。他们是较小的和松耦合的组件。服务类更容易理解，维护和重用。

这两个简单的步骤将帮助我们使得我们的应用程序架构更干净，有助于同行开发商提高生产力。

文章目录