在领域模型中，我们使用实体和对象来描述事物，但有的时候我们要描述的东西它可能并不是事物，也许就是一个过程或者行为，这时候领域服务就起到作用了。
在DDD中，将领域服务定义为“当某个操作不适合放在聚合和值对象的时候，最好的方式就是使用领域服务”。
上面这句话显得有些晦涩，我们回想一下在OOP当中的情况。
我们建立了多个Java对象，每个对象包含自己的业务逻辑。但是，经常的我们需要多个Java对象的合作才能完成一个完整的行为。
或者，有时候我们就是把一个对象转换成另一对象而已，并没有什么业务场景之类的需要我们用对象去描述这么一个过程。
DDD也是一样的，根据领域进行建模，那么在建模过程我们就会发现需要对多个领域对象进行协调的过程，这个过程可能被表示为一个领域服务。这里注意，你可能觉得聚合跟也可以做到这点，确实如此，但那样的结果就是你会导致很多的聚合根相互依赖，形成一个庞大的树形结构。
亦或者，你觉得我们可以把领域服务的行为过程丢给客户端自己处理，我们只需要提供领域对象即可。这样的做法存在的问题是，对于一个客户端来说，我其实并不想了解太多你的业务逻辑，你这样的设计给客户端增加了太多的复杂性。
类似的，我们只是把一个领域对象转换成另一个领域对象，比如从用户系统的“用户”转换成消息系统的“发送者”，这样也可以表示为一个领域服务。
但请注意，我们仍然优先考虑使用领域对象去处理业务逻辑，在必要的时候再考虑领域服务，这样才不会导致出现贫血模型。
我们甚至可以将领域服务理解为“门面模式”，门的外面是客户端应用，门的里面是大量领域对象相互协作的场景，每个协作过程都对应了领域当中的业务过程。
如果你的领域对象构建正确，且领域服务对业务描述也正确，那么即使一个不懂得编程的领域专家也应该要能够看得懂你的代码，这或许可以成为一个检验的标准。
未待完续。。。
原文地址：https://www.cnblogs.com/lay2017/p/10459511.html
