DDD落地过程中区分领域服务于应用服务

前言

首先看下领域驱动设计中对应用层和领域层的解释：

image.png

从解释中我们可以看出，应用层的任务是与其他系统应用层合作、为领域层进行协调，实际上还包括了翻译等工作，具体工作可以参考一下我的上一篇博客： https://www.jianshu.com/p/e833fe5544c3
领域服务的主要职责是表达业务概念、业务状态、业务规则。
理论看起来终归是理论，落地的时候实际上两者没那么好划分，我们在落地过程中也做了一些探索，下面是我们的一些见解，仅供参考

领域服务于应用服务区分

1、从领域通用语言区分

• 领域层的所有对象，包括领域服务是符合领域通用语言的，即你写的领域服务要能用通用语言描述出来服务
• 应用服务不需要通用语言来描述

2、从圈复杂度区分

• 应用服务的逻辑的圈复杂度一般等于1，或者比较小，即代码只能有一条路径，或者有多条简单路径，如果有多条，那么产生多条路径的分支条件应该是依赖同一个领域对象，比如：
  此时虽然圈复杂度为2，但是canDo判断并没有对do的领域逻辑内部产生影响

method(){
    if(!domainModel.canDo()){
        return;
    }
    domainModel.do();
    
}

• 领域服务的逻辑的圈复杂度很可能是大于1的，即一个方法的代码可能有多条路径，比如:
  此时方法依赖领域对象的某个查询结果，利用这个结果去和其他服务或者其他聚合进行交互，然后根据交互的结果决定是否进行业务逻辑。和应用服务的逻辑相比，应用服务是domainModel自己查询然后自己做了业务决策，但是领域服务这里不是domainModel自己做了业务决策，而是领域服务通过判断第三方调用是否为真做了业务决策，即业务决策的制定是领域服务做的，这就是业务逻辑。

method(){
    if(!domainModel.canDo()){
        return;
    }
    int param = domainModel.someField();
    boolean result = thirdPart.callWith(param);
    if(!result){
        return;
    }
    domainModel.do();
}

3、从与其他系统交互区分

• 应用服务会与其他系统进行交互，交互的目的多半是为了给领域层准备领域对象，比如调用Repository取对象、调用缓存取对象、调用其他业务系统为领域层准备对象等。
• 领域服务一般只依赖当前领域的对象，不会依赖外部的系统，当然特殊时候也会有对外部系统的依赖，但这个特殊时候对外部的依赖也是符合领域通用语言的。另外领域服务的入参应该是实体或者值对象，出参一般是值对象
• 总之，应用服务离外部更近、领域服务离外部很远