CQRS 和电子邮件通知
阅读 CQRS 时，有很多关于电子邮件通知的讨论 - 我想知道从哪里获取数据。想象一个场景，其中一个用户邀请其他用户参加一个活动。为了通知用户他已被邀请参加某个活动，系统会向他发送一封电子邮件。
具体步骤可能如下所示：
- 服务器接收带有要邀请的关联用户集合的 CreateEvent 命令。
- 将创建一个新的
Meeting聚合，并为每个要邀请的用户调用一个InviteUser方法。 - 每次邀请用户参加活动时，都会引发域事件
UserWasInvitedToEvent。 - 电子邮件通知发件人获取域事件并发出通知电子邮件。
现在我的问题是：我在哪里可以找到要包含在电子邮件中的信息？
假设我想包含事件的描述以及用户的姓名。由于这是 CQRS，我无法通过我的域模型获取它；域对象的所有属性都是私有的！然后我应该查询读取端吗？或者也许将电子邮件通知完全转移到不同的服务？
Reading up on CQRS there is a lot of talk of email notification - i'm wondering where to get the data from. Imagine a senario where one user invites other users to an event. To inform a user that he has been invited to an event, he is sent an email.
The concrete steps might go like this:
- A
CreateEventcommand with an associated collection of users to invite, is received by the server. - A new
Meetingaggregate is created and a methodInviteUseris called for each user that is to be invited. - Each time a user is invited to an event, a domain event
UserWasInvitedToEventis raised. - An email notification sender picks up the domain event and sends out the notification email.
Now my question is this: Where do I go for information to include in the email?
Say I want to include a description of the event as well as the user's name. Since this is CQRS I can't get it thru my domain model; All the properties of the domain objects are private! Should I then query the read side? Or maybe move email notification to a different service entirely?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在 CQRS 中，您将命令与查询端分开。您总是希望转到查询端以获取给定事件处理程序的数据。写入数据库将是一个单独的数据库，其中包含构建域对象所需的数据，并且不会针对读取进行优化，而是针对写入进行优化。
EventCreated事件。这可以从Meeting聚合的构造函数中引发。EventCreated事件，并使用事件中包含的数据（即事件的ID 及其名称）更新查询数据库。UserWasInvitedToEvent并使用任何必要的报告数据更新查询存储。UserWasInvitedToEvent事件。此过程可以访问查询数据库并提取发送电子邮件所需的所有数据。查询数据库只不过是一个报告数据库，因此您甚至可以拥有一个特定的表，将电子邮件所需的所有数据存储在一个位置。
为了将多个不同的事件编排到单个处理程序中（假设事件可能在不同时间以不同顺序处理），您可以利用 Saga 在您的消息总线中。 NServiceBus 是支持 Saga 的消息总线示例。另请参阅此 StackOverflow 问题：NServiceBus 延迟消息处理。
In CQRS, you're separating the command from the query side. You will always want to go to the query side in order to get data for a given event handler. The write database is going to be a separate database that contains the data necessary for building up your domain objects and will not be optimized for reads, but for writes.
EventCreatedevent to the event handlers / processors. This could be raised from the constructor of theMeetingaggregate.EventCreatedevent, and update the query database with the data contained in the event (ie, the Id of the event and its name).UserWasInvitedToEventevent to the event processors.UserWasInvitedToEventand update the query store with any reporting data necessary.UserWasInvitedToEventevent. This process could have access to the query database and pull back all of the data necessary for sending the email.The query database is nothing more than a reporting database, so you could even have a specific table that stores all of the data required for the email in one place.
In order to orchestrate several different events into a single handler (assuming the events might be processed in a different order at different times), you could utilize the concept of a Saga in your messaging bus. NServiceBus is an example of a messaging bus that supports Saga's. See this StackOverflow question as well: NServiceBus Delayed Message Processing.