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、缓存、其他服务等去完成一个业务过程的时候࿰