做DDD的项目，迟早都会遇到一个问题：聚合根放不下的逻辑，到底往哪放？
有人说领域服务是可选的，聚合根本身就能承载大部分业务逻辑，领域服务只是补充。
看起来是对的，其实错的离谱。但凡真正做过复杂业务的人都会发现，领域服务一定会出现。
因为聚合根是封闭的计算单元，只负责维护自己的状态，不碰数据库，不调外部接口。
但现实中的很多业务规则，都需要依赖数据库、其他微服务或者外部系统的数据才能完成。这些职责显然不应该放到聚合根里面。
那放应用服务里行不行？项目初期当然可以。
但随着业务越来越复杂，应用服务里的业务规则会越来越多，最后一个接口几百行代码，应用服务越来越胖，领域模型反而越来越薄，DDD最终又退化成了传统三层架构。
所以，当应用服务开始承担越来越多领域规则的时候，就应该把这些稳定的业务规则下沉到领域服务。
领域服务不是可选项，而是DDD真正落地以后必然会出现的一层。
在我参与的项目里，领域服务主要承担三类职责。
第一，依赖外部数据才能完成的领域计算。
第二，聚合根放不下的批量业务规则。
第三，无法归属于某一个聚合根的领域规则。
这些都属于业务规则，本质上应该留在领域层，而不是应用层。
另外还有一条原则，必须坚守的，就是领域服务之间禁止互相调用。
一旦允许领域服务互调，今天A调B，明天B调C，领域层很快就会变成一张蜘蛛网，最后和传统三层架构里Service相互调用没有区别。
跨聚合、跨模块的协调，应该交给应用服务。应用服务负责流程编排，领域服务负责业务规则，两者职责不要混在一起。
那领域服务里能不能调用其他微服务？
答案是：能，但必须通过防腐层。
领域服务不能直接依赖Dubbo、Feign这些RPC框架，而是应该依赖Domain层定义的Gateway接口，由基础设施层负责具体实现。这样领域层始终依赖抽象，而不是依赖技术框架。
小结：
领域服务存在的意义，不是为了让DDD看起来更规范，而是为了给那些放不进聚合根、又属于领域规则的逻辑，找到一个真正合适的归宿。
我一直坚持两个原则：
1，领域服务必须存在。
2，领域服务之间禁止互相调用。
当你发现应用服务越来越臃肿、领域模型越来越薄的时候，通常不是DDD有问题，而是你的领域服务，该出现了。