实现领域驱动设计-07-领域服务

  领域中的服务表示一个无状态的操作，它用于实现特定于某个领域的任务。当某个操作不适合放在聚合和值对象上时，为了避免过程式的编程方式，最好的方式便是使用领域服务来实现该操作。

什么是领域服务?

   当领域中的某个操作过程或转换过程不是实体或者值对象的职责时，我们应该将该操作放在一个单独的接口中，即领域服务。请确保该领域服务和业务、技术通用语言是一致的；并且保证它是无状态的；并且能够明确地表达限界上下文中的通用语言。

另外一种解释：
   在战术建模当中，并非所有模型都是事物。有些模型是对 领域中的一些行为操作进行建模。此类模型我们称之为领域服务。
   我们希望在领域设计当中统一用模型对象进行交互。此时领域服务使用细粒度的领域对象如实体或者值对象进行交互，在服务内部描述领域知识得出结果并将其返回（即领域服务的参数和返回类型应该是领域对象）。

   通常来说，领域模型主要关注于某个特定于某个领域的业务，同样，领域服务也具有相似的特点，以下是需要使用领域服务的三个特征：

• 它是与领域相关的操作，如执行一个显著的业务操作过程，但它又并不适合放入实体与值对象中。
• 对领域对象进行转换，或以多个领域对象作为输入进行计算，结果产生一个值对象
• 操作是无状态的

区分不同的服务

   在传统的开发中我们已经有 Service 服务的概念了，这时候再引入领域服务时，我们可能就会开始混淆。 在领域驱动设计中我们主要将服务分为三类，一类是应用服务，一类是领域服务，一类是基础服务。

   如何去区分这三种服务呢？简单的理解是通过服务自身所服务的客户端来进行区分。

• 应用服务提供面向用户的服务，它所完成的是一整个用户需求。
• 领域服务提供面向应用层的服务，它所完成的是封装领域知识，供应用层使用。
• 基础服务提供面向应用层和领域层的服务，它所提供的是项目中各个层都可能使用到的通用功能。

我们举一个银行转账的例子，通过不同服务所处理的事情来说明

• 应用服务：获取输入，发送消息给领域层，监听确认消息，决定使用基础服务来发送邮件。
• 领域服务：协调账户模型和总账模型进行交互，执行相应的领域行为。
• 基础服务：按照应用服务的指示发送邮件。

是否需要一个领域服务

   请不要倾向于将一个领域概念建模成领域服务，而是只有在有必要的时候才这么做。过度地使用领域服务将导致贫血领域模型，即所有的业务逻辑都位于领域服务中。

领域服务使用案例分析

场景：
   我们需要对一个 User 进行认证（不能使用明文密码），并且只有当 Tenant 处于激活状态时，我们才会通过认证。

V1

从应用服务层来讲，我们的实现可能如下:

boolean authentic=false;
User user  = DomainRegistry.userRepository().userwithUsername(aTenantId,ausername);
if (user != null){authentic= user.isAuthentic(aPassword);
}
return authentic;

   对于以上设计，存在如下几个问题。

• 应用服务层需要知道某些认证细节，他们需要找到一个User,然后再对该User进行密码匹配。
• 不能显式地表达通用语言。这里，我们询问的是一个Usr“是否被认证了”，而没有表达出“认证”这个过程。在有可能的情况下，我们应该尽量使建模术语直接地表达出团队成员的交流用语。
• 缺少了“检查Tenant是否处于激活状态”这个前提条件。如果一个User所属的Tenant处于非激活状态，我们便不应该对该User进行认证。

V2

//客户端查找User,然后User完成自我认证
boolean authentic=false;
Tenant tenant=DomainRegistry.tenantRepository().tenantofId(aTenantId);
if (tenant != null && tenant.isActive()){User user = DomainRegistry.userRepository().userWithUsername(aTenantId,aUsername);if(user！=nu11){authentic = tenant.authenticate(user,aPassword);}
}
return authentic;

   这种方式也存在一些问题：

• 应用服务层需要知道更多的认证细节，而这些是应用服务层可以不感知的东西。
• 我们可以将Tenant 的isActive() 方法放在 authenticat() 方法中，减少应用服务层需要感知的认证细节。但这并不是一个显式的模型行为。同时，这将带来另外一个问题，即此时的Tenant需要知道如何对密码进行操作。

V3

   对于以上解决方案，我们似乎给模型带来了太多的问题。对于V2，
我们可以从如下几种方面去思考解决方案：

1. 在Tenantr中处理对密码的加密，然后将加密后的密码传给User。这种方法违
   背了单一职责原则。

2. 由于一个User 必须保证对密码的加密，它可能已经知道了一些加密信息。如
   果是这样，我们可以在Usr上创建一个方法，该方法对明文密码进行认证。

3. Tenant依赖于User对密码进行加密，然后将加密后的密码与原有密码进行匹
   配。这种方法在对象协作之间增加了额外的步骤。此时，Tenant依然需
   要知道认证细节。

4. 让客户端对密码进行加密，然后将其传给Tenant。这样导致的问题在于，应用服务层承载了它本不应该有的职责。

   以上这些方法都会带来一些问题，应用服务层处理逻辑变的复杂、应用服务负责了对身份与访问权限的管理等。

//应用服务只用于协调任务
UserDescriptor userDescriptor= DomainRegistry.authenticationservice().authenticate(aTenantId,aUsername,aPassword);

public class UserDescriptor implements Serializable{
private String emailAddress;
private TenantId tenantId;
private String username;public UserDescriptor(TenantId aTenantId,String aUsername,String anEmailAddress){....
}
}

   应用服务只需要获取到一个无状态的AuthenticationService,然后调用它的authenticate()方法即可。将所有的认证细节放在领域服务中，而不是应用服务。

   在需要的情况下，领域服务可以使用任何领域对象来完成操作，包括对密码的加密过程。客户端不需要知道任何认证细节。