DDD落地过程中关于领域服务的思考

前言

DDD架构分层由内到外主要分为domain层->application层->infrastructure层->interface层
其中领域服务属于domain层、应用服务属于application层，领域服务的实现和application的实现都在infrastructure层。
应用服务没有领域逻辑，仅仅是对领域层case的编排，比如先调a再调b，这种case流
领域服务包含业务逻辑，那么包含哪些业务逻辑就是我们今天讨论的主题。

领域服务的业务逻辑

1、什么时候使用领域服务

• 执行一个显著的业务过程
• 对领域对象进行转换
• 以多个领域对象作为输入进行计算，结果产生一个值对象

以上说法来自于实现领域驱动设计，那么我们自己的理解呢？

2、实践过程中引入领域服务

• 在落地领域驱动设计的时候我们常常会遇到这种困惑，即在一个聚合中想要引用另一个聚合，然后两个聚合合作完成一个业务过程。
  这个时候如果我们从聚合角度出发会产生三种想法：
  a、在聚合A中引入聚合B的Repository
  b、在聚合A的方法中以入参形式引入聚合B
  c、直接在聚合A中组合聚合B
  第一种和第三种有违领域驱动设计初衷，第二种虽然可行，但是语义上会存在不通顺的情况。所以，在我们遇到以上三种情况的困惑是领域服务就是我们的解药。
• 对于一些验证逻辑，比如某个属性是不是已经存在等可以写在领域服务中，由领域服务的实现层直接调用缓存或者数据库查询。更抽象一些就是需要依赖聚合之外的如数据库、Repository、缓存、其他服务等去完成一个业务过程的时候，需要引入领域服务。
• 对于同一种聚合，如聚合A，有多个聚合A的实例，实际上就是多个聚合，只不过聚合的class类相同。这种多聚合合作也需要引入领域服务。

3、避免贫血模型

• 过度的使用领域服务会导致贫血领域模型，业务逻辑尽量写到聚合和值对象中
• 有些情况下我们会逼不得已使用领域服务完成一个“显著”的业务过程，这个显著的业务过程会非常“厚”。此时我们应该提高警惕，是不是领域限界上下文划分错误，导致一些不属于领域限界上下文的聚合被建模进来。

4、领域服务代码设计

• 领域服务尽量只依赖Repository去完成领域事件，具体业务逻辑应该由Repository中的聚合来完成
• 次之，领域服务引入了获取聚合的缓存对象。
• 再次之，需要调用其他上下文的服务来完成领域事件，此时需要明确建立“防腐层”

总之，领域服务尽量避免写太多业务逻辑，导致贫血模型产生。