在DDD中谁应该处理域事件？ [英] In DDD, who should be resposible for handling domain events?

问题描述

谁应负责处理域名事件？应用服务，域服务或实体本身？

让我们使用这个问题的简单例子。假设我们在商店应用上工作，我们有一个致力于订单操作的应用服务。在此应用程序中订单是一个聚合根和以下规则，我们只能在单个事务中使用一个聚合。放置订单后，它将保留在数据库中。但还有更多的事要做。首先，我们需要更改库存中可用的项目数量，其次通知系统的其他部分（可能是另一个有界的上下文），该特定订单的发货程序应该开始。因为，如已经说明的那样，我们只能在事务中修改一个聚合，我想考虑发布将由单独事务中的某些组件处理的 OrderPlacedEvent 。

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

解决方案

p>我想：

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

2）如果事件触发某些基础设施服务，应用层。

eg电子邮件发送给客户。因此，需要一个应用程序服务来加载邮件内容和邮件的订单，然后调用基础设施服务来发送邮件。

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

eg运输或计费，域服务的基础架构实施负责整合其他有限的上下文。

4）如果事件需要拆分为多个消费者，则基础设施层。消费者去1），2）或3）。

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

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

Who should be responsible for handling domain events? Application services, domain services or entities itself?

Let's use simple example for this question.

Let's say we work on shop application, and we have an application service dedicated to order operations. In this application Order is an aggregate root and following rules, we can work only with one aggregate within single transaction. After Order is placed, it is persisted in a database. But there is more to be done. First of all, we need to change number of items available in the inventory and secondly notify some other part of a system (probably another bounded context) that shipping procedure for that particular order should be started. Because, as already stated, we can modify only one aggregate within transaction, I think about publishing OrderPlacedEvent that will be handled by some components in the separate transactions.

Question arise: which components should handle this type of event?

解决方案

I'd like to:

1) Application layer if the event triggers modification of another Aggregate in the same bounded context.

2) Application layer if the event trigger some infrastructure service.

e.g. An email is sent to the customer. So an application service is needed to load order for mail content and mail to and then invoke infrastructure service to send the mail.

3) I prefer a Domain Service personally if the event triggers some operations in another bounded context.

e.g. Shipping or Billing, an infrastructure implementation of the Domain Service is responsible to integrate other bounded context.

4) Infrastructure layer if the event need to be split to multiple consumers. The consumer goes to 1),2) or 3).

For me, the conclusion is Application layer if the event leads to an seperate acceptance test for your bounded context.

By the way, what's your infrastructure to ensure durability of your event? Do you include the event publishing in the transaction?

这篇关于在DDD中谁应该处理域事件？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！