领域驱动设计系列文章

http://www.jdon.com/45857

Spring的web应用程序:

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

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

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

服务层有两个主要问题：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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