DDD之领域事件与领域服务

领域服务

领域中的服务表示一个无状态的操作，它用于实现特定于某个领域的任务。当某个操作不适合放在聚合和值对象上时，最好的方式便是使用领域服务。具体的使用场景可参考以下几大特点：

• 执行一个显著的业务操作过程（值对象就不具备业务操作行为）

• 对领域对象进行转换

• 以多个领域对象作为输入进行计算，结果产生一个值对象。（实体对象无论到什么时候都具备业务行为，而领域服务的产出结果是一个不具备业务行为的值对象）

业务逻辑的处理还是要尽量的放在实体对象和值对象中体现，尽量不要过度的依赖领域服务，过度地使用领域服务将导致贫血领域模型。

领域事件是在领域内发生时需要有进一步业务操作的事件，比如订单支付完成后，需要发送一条结果通知信息就属于一个领域事件。在进行事件风暴时，当我们听到“如果发生……，则……”“当做完……的时候，请通知……”“发生……时，则……”等这些关键词时，我们要意识到在这些场景中，如果发生某种事件后，会触发进一步的操作，那么这个事件很可能就是领域事件。

在分布式架构下，领域事件有助于业务解耦和形成完整的业务闭环。领域事件发生在微服务之间的场景比较多，事件处理的机制也更加复杂。跨微服务的事件可以推动业务流程或者数据在不同的子域或微服务间直接流转。跨微服务的事件机制要总体考虑事件构建、发布和订阅、事件数据持久化、消息中间件，甚至事件数据持久化时还可能需要考虑引入分布式事务机制等。

1、这里其实可以将领域事件简单的理解成一个微服务的通信事件，按照流行技术架构的设计应该采用的是MQ，虽然也可以通过RPC实现事件通信，但是为了系统解耦、业务行为更具有独立性，通常还是通过消息中间件的方式。虽然这样理解领域事件过于狭隘，但是也比较直观。

2、不建议在微服务的内部聚合之间使用领域事件，这种场景的实现成本过高收益过小，通常这种场景都有其他更好的替换方式。

一个标准的领域事件处理包括：事件构建和发布、事件数据持久化、事件总线、消息中间件、事件接收和处理等几大环节。

（不建议在微服务内部使用领域事件通信）

领域事件是 DDD 的一个重要概念，在设计时我们要重点关注领域事件，用领域事件来驱动业务的流转，尽量采用基于事件的最终一致，降低微服务之间直接访问的压力，实现微服务之间的解耦，维护领域模型的独立性和数据一致性。