四、领域服务、工厂、资源库

一、领域服务

在领域模型中，我们使用实体和对象来描述事物，但有的时候我们要描述的东西它可能并不是事物，也许就是一个过程或者行为，这时候领域服务就起到作用了。

在DDD中，将领域服务定义为“当某个操作不适合放在聚合和值对象的时候，最好的方式就是使用领域服务”。

上面这句话显得有些晦涩，我们回想一下在OOP当中的情况。

我们建立了多个Java对象，每个对象包含自己的业务逻辑。但是，经常的我们需要多个Java对象的合作才能完成一个完整的行为。

或者，有时候我们就是把一个对象转换成另一对象而已，并没有什么业务场景之类的需要我们用对象去描述这么一个过程。

DDD也是一样的，根据领域进行建模，那么在建模过程我们就会发现需要对多个领域对象进行协调的过程，这个过程可能被表示为一个领域服务。这里注意，你可能觉得聚合跟也可以做到这点，确实如此，但那样的结果就是你会导致很多的聚合根相互依赖，形成一个庞大的树形结构。

亦或者，你觉得我们可以把领域服务的行为过程丢给客户端自己处理，我们只需要提供领域对象即可。这样的做法存在的问题是，对于一个客户端来说，我其实并不想了解太多你的业务逻辑，你这样的设计给客户端增加了太多的复杂性。

类似的，我们只是把一个领域对象转换成另一个领域对象，比如从用户系统的“用户”转换成消息系统的“发送者”，这样也可以表示为一个领域服务。

但请注意，我们仍然优先考虑使用领域对象去处理业务逻辑，在必要的时候再考虑领域服务，这样才不会导致出现贫血模型。

我们甚至可以将领域服务理解为“门面模式”，门的外面是客户端应用，门的里面是大量领域对象相互协作的场景，每个协作过程都对应了领域当中的业务过程。

如果你的领域对象构建正确，且领域服务对业务描述也正确，那么即使一个不懂得编程的领域专家也应该要能够看得懂你的代码，这或许可以成为一个检验的标准。

二、工厂

工厂模式想必大家都很熟悉，它属于23种设计模式当中创建型模式，主要用来创建复杂的对象。DDD领域模型中，也存在一个工厂的概念，它用于将聚合根复杂的构建过程进行细节隐藏，只需要面对一个创建接口即可。

需要关注的一点是，在DDD中工厂的概念不仅仅是工厂模式的重现，领域服务同样也可以设计成为一个工厂。代码示例：

/**
* 领域服务
*/
public class UserService {
    public User userFrom(String tenantId) {
        // 调用防腐层
        return new UserAdapter().user(tenantId);
    }
}
/**
* 防腐层
*/
public class UserAdapter {
    public User userFrom(String tenantId) {
        String url = "http://test:8080/getUser?tenantId=" + tenantId
        String json = httpClient.sendRequest(url, Method.GET);
        User user = JSON.parseObject(json, User.class);
        return user;
    }
}

以上代码采用领域服务来构建一个User实体，而领域服务去调用防腐层来从远程获取。我们可以看到，User对象从数据获取到解析构建的过程都被隐藏起来了，而UserService就变得像是一个工厂一样，隐藏了User实体的构建过程。

所以，对于工厂模式来说，隐藏创建过程才是它的核心思想。

三、资源库

领域对象始终是一个内存的东西，当应用程序关闭下次进来的时候它就不见了。所以，我们得对一些东西进行持久化，DDD中以资源库的概念来满足持久化的需要。

持久化的最佳实现是对一整个聚合进行持久化，也就是说我们面向的不是一个单一的对象，而是对高内聚的聚合对象进行统一持久化，并且统一查询出来，这样资源库和领域模型中的聚合就形成了一对一的关系。

对聚合进行持久化得满足“幂等性”，也就是说，不能重复创建两份数据，这应该比较容易理解，因为实体是具有唯一性的，重复的数据形成了两个聚合，它是没有意义的。

资源库和我们一般的DAO层存在本质的区别，DAO层所面向的是数据库，对数据库的数据进行CRUD操作。而资源库面向的是我们领域模型中的聚合，针对聚合设计持久化操作。

另外，从技术角度考虑，我们或许会把资源库和数据映射器放在同等的位置，在实现上进行简化处理。

 

转载于:https://www.cnblogs.com/lay2017/p/10459511.html