DDD，聚合可以处理来自另一个聚合的事件吗？
处理从另一个聚合发布的聚合中的事件是否正确？或者域应该只处理命令？
就我而言，我有一个管理设置的应用程序。我有一个应用程序聚合和一个 applicationGroup 聚合。当我想为特定的应用程序组创建设置时，该命令由我的 applicationGroup 处理，然后 applicationGroup 发布一个事件 GroupSettingsCreated ，但是 DDD 是否说我们可以直接在我的 ApplicationAggregate 中处理此事件？或者我应该在事件处理程序中处理此事件，将其映射到命令中，然后将其发送到我的 ApplicationAggregate ？
谢谢
约翰
Is it right to handle an event in a aggregate published from another aggregate ? Or a domain should only handle commands ?
In my case, I have an application which manages settings. I have an aggregate for application and an aggregate for applicationGroup. When I want to create a settings for a specific group of applications, then the command is handled by my applicationGroup, then the applicationGroup publish an event GroupSettingsCreated, but does DDD say we can handle this event directly in my ApplicationAggregate ? Or should I handle this event in an event handler ,map it into a command then send it to my ApplicationAggregate ?
Thanks
John
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您想在另一个聚合中处理一个聚合的事件，则处理程序应该是生成事件的聚合的子级。
换句话说，在这个 有界上下文 中，
Application应该是 < code>ApplicationGroup 和ApplicationGroup.CreateSettings()应将设置传播到其子应用程序。另一种思考方式是：“应用程序组”可能不是真正的聚合，而是用户界面提供的便利。
If you're tempted to handle one aggregate's event inside another aggregate, the handler should be a child of the aggregate generating the event.
In other words, in this bounded context,
Applicationshould be a child ofApplicationGroupandApplicationGroup.CreateSettings()should propagate settings to its child applications.Another way to think of this: an "application group" might not be a true aggregate - but rather a convenience provided by the user interface.
John，我不知道 DDD 中有任何内容可以解答您的问题。这实际上是一个事件驱动架构 (EDA) 和命令查询职责分离 (CQRS)。
为了提供更具体的建议，我想知道应用程序和 applicationGroup 实体扮演什么角色。顺便说一句，它们听起来更像是应用程序/基础设施概念，而不是领域概念。
一般来说，我使用的命令从逻辑上从源推送下一个操作（下一个操作是必要的下一步）。当相关操作在逻辑上是对上游行为的反应（上游代码不知道对刚刚发生的事情的反应）时，我使用事件。
John, I don't know of anything in DDD that speaks to your question. This is really a question of Event Driven Architecture (EDA) and Command Query Responsibility Segregation (CQRS).
To give more specific advice, I'd like to know what roles the application and applicationGroup entities play. BTW, they sound more like application/infrastructure concepts than domain concepts.
In general, I use commands where the next action is logically pushed from the source (the next action is a necessary next step). I use events when the action in question is logically a reaction to the upstream behavior (the upstream code is unaware of this reaction to what just happened).
你不应该这样做，因为它会导致代码混乱。相反，使用 sagas 来进行 am编排。 这里还有来自 Andreas Öhlund 的有关 NServiceBus 传奇的精彩视频。
You shouldn't do it in this way cause it will lead to a messy code. Instead, use sagas for am orchestration. Here is also good video from Andreas Öhlund on sagas in NServiceBus.