在 DDD 中，谁应该负责处理领域事件？答案

【问题标题】：In DDD, who should be resposible for handling domain events?在 DDD 中，谁应该负责处理领域事件？
【发布时间】：2018-07-07 00:47:25
【问题描述】：

谁应该负责处理领域事件？应用服务、领域服务还是实体本身？

让我们用一个简单的例子来回答这个问题。

假设我们处理商店应用程序，并且我们有一个专门用于订单操作的应用程序服务。在这个应用程序中，Order 是一个聚合根，遵循规则，我们只能在单个事务中使用一个聚合。下订单后，它会保存在数据库中。但还有更多工作要做。首先，我们需要更改库存中可用商品的数量，然后通知系统的其他部分（可能是另一个有界上下文）应该启动该特定订单的运输过程。因为，如前所述，我们只能在事务中修改一个聚合，所以我考虑发布OrderPlacedEvent，这将由单独事务中的某些组件处理。

问题出现：哪些组件应该处理这种类型的事件？

【问题讨论】：

标签： events domain-driven-design

【解决方案1】：

我想：

1) 应用层，如果该事件触发了对同一有界上下文中另一个聚合的修改。

2) 事件触发某些基础设施服务时的应用层。

例如一封电子邮件被发送给客户。所以需要一个应用服务来加载邮件内容和邮件的顺序，然后调用基础设施服务来发送邮件。

3) 如果事件在另一个有界上下文中触发某些操作，我个人更喜欢域服务。

例如运输或计费，领域服务的基础设施实现负责集成其他有界上下文。

4) 如果需要将事件拆分给多个消费者，则为基础设施层。消费者选择 1),2) 或 3)。

对我来说，如果事件导致有界上下文的单独验收测试，则结论是应用层。

顺便问一下，确保活动持久性的基础设施是什么？您是否在事务中包含事件发布？

【讨论】：

感谢您的回复。关于耐用性 - 我还不知道如何组织它。我认为理想情况下，我们应该有两个事务和一些持久队列（JMS？） - 事件在同一个事务中发布，因此我们确保它被正确传递，并且在从队列中提取消息时启动另一个事务。这样我们可以确保如果出现问题，事件将被重新传递

【解决方案2】：

这类处理程序属于应用层。您可能也应该创建一个支持应用程序服务的方法。这样你就可以开始单独的事务了。

【讨论】：

【解决方案3】：

我认为放置 EventHandler 的最常见和最常见的位置是 application layer。与 CQRS 类比，EventHandler 与 CommandHandler 非常相似，我通常将它们放在一起（在应用层）。

来自 Microsoft 的

This article 还提供了一些将处理程序放在那里的示例。请看下面的图片，取自相关文章：

【讨论】：