Events 在DDD中，谁应该负责处理域事件？

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

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

比如说，我们致力于商店应用程序，我们有一个专门用于订单操作的应用程序服务。在这个应用程序中，

Order

是一个聚合根目录，根据以下规则，我们只能在单个事务中使用一个聚合。下订单后，订单将持久保存在数据库中。但还有更多的工作要做。首先，我们需要更改库存中可用项目的数量，然后通知系统的某些其他部分（可能是另一个有界上下文），应该启动该特定订单的装运程序。因为，如前所述，我们只能在事务中修改一个聚合，所以我考虑发布将由单独事务中的某些组件处理的

OrderPlacedEvent

---

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

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

我想：

1） 应用程序层，如果事件触发修改同一有界上下文中的另一个聚合

2） 如果事件触发某些基础结构服务，则为应用程序层

e、 g.向客户发送电子邮件。因此，需要一个应用程序服务来加载邮件内容和邮件的订单，然后调用基础结构服务来发送邮件

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

e、 g.发货或计费，域服务的基础设施实现负责集成其他有界上下文

4） 如果事件需要拆分为多个使用者，则为基础结构层。消费者选择1）、2）或3）

对我来说，如果事件导致对您的受限上下文进行单独的验收测试，那么结论就是应用层

---

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

我认为放置事件处理程序的最常见和最常见的位置是

应用程序层。通过与CQR进行类比，EventHandler与CommandHandler非常相似，我通常将它们彼此放在一起（在应用层）

微软也给出了一些将处理程序放在那里的例子。请看下面的图片，摘自相关文章：

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