DDD里的领域服务，到底什么时候该用？

做DDD的项目，迟早都会遇到一个问题：聚合根放不下的逻辑，到底往哪放？

有人说领域服务是可选的，聚合根本身就能承载大部分业务逻辑，领域服务只是补充。

看起来是对的，其实错的离谱。但凡真正做过复杂业务的人都会发现，领域服务一定会出现。

因为聚合根是封闭的计算单元，只负责维护自己的状态，不碰数据库，不调外部接口。

但现实中的很多业务规则，都需要依赖数据库、其他微服务或者外部系统的数据才能完成。这些职责显然不应该放到聚合根里面。

那放应用服务里行不行？项目初期当然可以。

但随着业务越来越复杂，应用服务里的业务规则会越来越多，最后一个接口几百行代码，应用服务越来越胖，领域模型反而越来越薄，DDD最终又退化成了传统三层架构。

所以，当应用服务开始承担越来越多领域规则的时候，就应该把这些稳定的业务规则下沉到领域服务。

领域服务不是可选项，而是DDD真正落地以后必然会出现的一层。

在我参与的项目里，领域服务主要承担三类职责。

第一，依赖外部数据才能完成的领域计算。

第二，聚合根放不下的批量业务规则。

第三，无法归属于某一个聚合根的领域规则。

这些都属于业务规则，本质上应该留在领域层，而不是应用层。

另外还有一条原则，必须坚守的，就是领域服务之间禁止互相调用。

一旦允许领域服务互调，今天A调B，明天B调C，领域层很快就会变成一张蜘蛛网，最后和传统三层架构里Service相互调用没有区别。

跨聚合、跨模块的协调，应该交给应用服务。应用服务负责流程编排，领域服务负责业务规则，两者职责不要混在一起。

那领域服务里能不能调用其他微服务？

答案是：能，但必须通过防腐层。

领域服务不能直接依赖Dubbo、Feign这些RPC框架，而是应该依赖Domain层定义的Gateway接口，由基础设施层负责具体实现。这样领域层始终依赖抽象，而不是依赖技术框架。

小结：
领域服务存在的意义，不是为了让DDD看起来更规范，而是为了给那些放不进聚合根、又属于领域规则的逻辑，找到一个真正合适的归宿。

我一直坚持两个原则：

1，领域服务必须存在。

2，领域服务之间禁止互相调用。

当你发现应用服务越来越臃肿、领域模型越来越薄的时候，通常不是DDD有问题，而是你的领域服务，该出现了。