领域服务、领域事件_领域事件领域服务-CSDN博客

本文链接：https://blog.csdn.net/lijingyao8206/article/details/50867008

本文探讨了领域服务的概念，强调其与应用服务的区别，并解释了领域事件的聚合、发布及其在保证最终一致性中的作用。文章通过借书案例阐述了事件模型的创建，提出在处理分布式事件时的一致性策略，包括共享存储、全局事务和本地EventStore。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

综合前两篇总结，这篇对领域服务和领域事件做一个梳理。先说明下本文的领域服务和应用服务。SOA服务，或者应用间的RPC调用，Restful接口，或者通过消息中间件进行系统间的交互的，都可以归类为应用服务。相较之下，领域服务不一定涉及到远程调用或者重量级事务操作。所以上下文集成也就涉及到，怎样的方式去划分限界上下文，怎么样设计才能尽量减少应用服务的耦合，以及应用服务对于本地模型的防腐。

领域服务

概念

借用《Implementing Domain-driven Design》里面的对于领域服务的定义。领域的某个操作过程或转换过程不是实体或值对象的职责时，应该将操作放在一个单独的接口中，即领域服务，并且要和通用语言保持一致。这里的非实体或值对象操作会有很多种情况，比如某个操作需要对多个领域对象操作，输出一个值对象。在分层的架构中，有点类似于Manager。但是如果过渡抽象manager就会出现贫血，所以还需要确保领域服务是无状态的，并且做好和贫血模型的权衡。可能大多数情况，领域服务的参数都是比实际的领域模型小的，只有些关键属性的值对象。如果服务只操作领域的实体或值对象，则可以考虑下放到domain model中操作。
前面提到了Manager,但是很多应用中都会把Manager抽象成接口的形式，但大多数情况其实完全没有必要，可以通过服务Factory的方式解耦，或者用Spring的@Service注解来注入真正的服务实现类。对于一些简单的领域操作，还可以抽象一个迷你层，这个迷你层也可以称作是领域服务，只不过是无状态，无事务，安全的一个抽象层。
领域事件其实也可以归纳为领域服务，不过领域服务的事件是幂等的。因为领域服务是无事务的，所以事件也是无副作用的，这样在处理聚合依赖的时候，需要保证他们的最终一致性。