第二部分：DDD中的 Service（领域服务）

目录

  Service（领域服务）

  好的Service的3个特征

   最佳实践

   不好案例

---

  Service（领域服务）

   定义：当领域中的某个操作过程或转换过程不是实体或值对象的职责时，便应该将该操作放在一个单独的接口中，即领域服务。

   定义接口时要使用模型语言 ，并确保操作名称来自通用语言的术语。此外，应该使Service成为是无状态的。

   引入时机：有时，对象并不是一个事物。在某些情况下，最清楚、最实用的设计会包含一些特殊的操作，这些操作从概念上讲不属于任何对象。与其把他们强制归属哪一类，不如顺其自然在模型中引入一种新元数，这就是服务（Service）。
     

    Service是作为接口提供的一种操作，它在模型中是独立的，它不像实体和值对象那样具有封装的状态。它强调的是与其他对象的关系。与实体和值对象不同，它只是定义了为客户做什么。Service往往是以一个活动命名，而不是以一个实体来命名。也就是说，他是动词不是名词。它也可以有抽象而有意义的定义，只是它使用了与对象不一样的风格。也应该有定义的职责，而且这种职责以及履行它的接口也应该作为领域模型的一部分加以定义。操作名应该来之通用语言，如果没有也应该将他引入到通用语言。领域服务结果应该是领域对象。领域服务也是领域层的入口 。

  好的Service的3个特征

1. 与领域相关的操作不是实体或值对象的一个自然组成部分
2. 接口是根据领域模型的其他元数定义的。
3. 操作是无状态的

     这里所说的无状态是指任何客户都可以使用某个Service的任何实例，而不关心该实例的历史状态。但是它可以是无状态的。

   最佳实践

1.  领域服务尽量使用动词来命名，如ProductDoService调整为ProductMakeDoService，除非领域服务的行为比较少且很简单。产生太多细粒度的领域服务，并不是问题。需要思考这些领域行为是否应该分配至聚合对象中。
2. 聚合之间的协作该由谁发起，放在哪个聚合上可能都不合适，可以考虑放在领域服务中。
3. 聚合与外部服务之间的协作，可以考虑放在领域服务中。
4. 领域服务不一定很复杂，有可能很简单：对实体的操作，再调用资源库进行保存。

   不好案例

1.  把所有的业务逻辑都放在领域服务中，容易导致贫血领域模型的出现，应优先分配给值对象、实体和聚合根中。
2. 领域服务的参数不应该是领域对象，不然这意味着业务逻辑泄漏至客户端（接入层/应用服务等），客户端是怎么获取领域对象的呢。
3. 不应该在应用层对领域层对象的行为进行协调。这种细粒度的领域对象可能会把领域层的知识泄露到应用层中。这产生的结果是应用层不得不处理复杂的、细致的交互，从而使得领域层知识蔓延到应用层或者用户界面代码当中，而领域层会丢失这些知识。最好的方式是引入领域层服务。