我怀疑有多少听众可以订阅特定域名事件的最佳策略。
假设在绑定上下文A中创建新用户时，我们发布了一个名为UserWasCreated的域事件。假设我们有另一个Bounded Context B订阅了该事件，我们必须在其中执行许多任务例如：发送电子邮件，持久保存用户的某些信息并将用户信息推送到外部服务（即CRM）。
我的问题是，在同一个有界上下文中，我应该为该事件提供多少听众？
我看过Vernon的IDDD书，每个事件只有一个听众，如UserWasCreatedListener。但是那个听众只有一个特定的责任，而在我的例子中涉及到不同的任务。
每个事件任务有一个监听器是否有意义？所以按照我们的例子：
UserWasCreated_NotifyByEmailListener
UserWasCreated_NotifyCrmListener
UserWasCreated_PersistUserListener
如果确实有意义，你会如何命名这些听众？是否存在任何可扩展性问题，因为创建了太多的侦听器？
答案 0 :(得分：2)
简短的答案直接与事件的听众（订阅者）数量有关：0到 N
我喜欢区分以下类型的事件：
原因是它们具有不同的含义，并且在许多情况下会带有不同的数据。
回到你的问题。您正在描述一个过程。进程通常由某些命令启动，或者在您的情况下由事件启动。可以通过两种方式驱动流程：
当消息编排时，他们非常被动。这意味着一个事件导致另一个事件。在你的情况下，你可以：
如果它是一个相当简单，顺序的流程，这些工作正常。当您需要用户干预时，例如检查项目或并行处理，事情往往会变得毛茸茸。
另一方面，Orchestraion 使用流程管理器来保持流程的状态并与各种原子服务进行交互。
在您的情况下，您可以拥有UserRegistrationProcess，以便在需要时进行实例化。在您的情况下，也许在用户创建上。另一种方法是启动流程并让 it 包括用户创建。您的UserRegistrationProcess将成为各种活动的订阅者。但是，不是各种监听器对任意事件作出反应，而是只为相关命令提供服务。
CreatedUserCommand发送到UserEndpoint（BC）UserCreatedEvent
CreateCrmUserCommand发送到CrmEndpoint（BC）CrmUserCreatedEvent
SendEMailCommand发送到EMailEndpoint（基础结构）
来自EMailEndpoint（基础设施）的Process receives the EMailSentEvent` 通过这种方式，流程图层本身就成为一个有界的上下文。
我更喜欢编排，因为您始终可以查看流程的进度。