有界上下文中有多少个侦听器可以订阅特定的域事件？

Question

我怀疑有多少听众可以订阅特定域名事件的最佳策略。

假设在绑定上下文A中创建新用户时，我们发布了一个名为UserWasCreated的域事件。假设我们有另一个Bounded Context B订阅了该事件，我们必须在其中执行许多任务例如：发送电子邮件，持久保存用户的某些信息并将用户信息推送到外部服务（即CRM）。

我的问题是，在同一个有界上下文中，我应该为该事件提供多少听众？

我看过Vernon的IDDD书，每个事件只有一个听众，如UserWasCreatedListener。但是那个听众只有一个特定的责任，而在我的例子中涉及到不同的任务。

每个事件任务有一个监听器是否有意义？所以按照我们的例子：

UserWasCreated_NotifyByEmailListener
UserWasCreated_NotifyCrmListener
UserWasCreated_PersistUserListener

如果确实有意义，你会如何命名这些听众？是否存在任何可扩展性问题，因为创建了太多的侦听器？

Answer 1

简短的答案直接与事件的听众（订阅者）数量有关：0到 N

我喜欢区分以下类型的事件：

• 域
• 活动采购
• 消息（系统）

原因是它们具有不同的含义，并且在许多情况下会带有不同的数据。

回到你的问题。您正在描述一个过程。进程通常由某些命令启动，或者在您的情况下由事件启动。可以通过两种方式驱动流程：

• 编排
• 编排

当消息编排时，他们非常被动。这意味着一个事件导致另一个事件。在你的情况下，你可以：

• UserCreatedEvent - ＆gt; PersistUserHandler（订阅者） - ＆gt; UserPersistedEvent
• UserPersistedEvent - ＆gt; CrmListener（订户） - ＆gt; CrmUserCreatedEvent
• CrmUserCreatedEvent - ＆gt; EMailNotifier（订户） - ＆gt; UserNotifiedEvent

如果它是一个相当简单，顺序的流程，这些工作正常。当您需要用户干预时，例如检查项目或并行处理，事情往往会变得毛茸茸。

另一方面，

Orchestraion 使用流程管理器来保持流程的状态并与各种原子服务进行交互。

在您的情况下，您可以拥有UserRegistrationProcess，以便在需要时进行实例化。在您的情况下，也许在用户创建上。另一种方法是启动流程并让 it 包括用户创建。您的UserRegistrationProcess将成为各种活动的订阅者。但是，不是各种监听器对任意事件作出反应，而是只为相关命令提供服务。

• 开始流程
• 进程将CreatedUserCommand发送到UserEndpoint（BC）
• 进程从UserEndpoint（BC）
接收UserCreatedEvent
• 流程将CreateCrmUserCommand发送到CrmEndpoint（BC）
• 进程从CrmEndpoint（BC）
接收CrmUserCreatedEvent
• 进程将SendEMailCommand发送到EMailEndpoint（基础结构） 来自EMailEndpoint（基础设施）的Process receives the EMailSentEvent`
• 终止流程

通过这种方式，流程图层本身就成为一个有界的上下文。

我更喜欢编排，因为您始终可以查看流程的进度。