CQRS and Email Notification

Reading on CQRS is a lot of talk about email notification - I wonder where to get the data. Imagine senario where one user invites other users to an event. An email was sent to inform the user that he was invited to the event.

Specific steps may look like this:

  • Team
  • A CreateEvent with an associated collection of invited users is accepted by the server.
  • A new Meeting aggregate is created and the InviteUser method is InviteUser for each user who should be invited.
  • Each time a user is invited to an event, a UserWasInvitedToEvent domain event is UserWasInvitedToEvent .
  • An email notification sender receives a domain event and sends an email notification.

My question now is: where do I go for information to include in my email?

Say I want to include a description of the event, as well as a username. Since this is CQRS, I cannot get it through my domain model; All properties of domain objects are private! Should I then request a read? Or is it possible to forward an email notification to another service?

+6
email notifications domain-driven-design cqrs
source share
1 answer

In CQRS, you separate the command from the request side. You will always want to go to the request page to get data for this event handler. The write database will be a separate database that contains the data necessary for creating domain objects and will not be optimized for reading, but for writing.

  • The domain must register and dispatch the EventCreated event to event handlers / processors. This may be due to the Meeting aggregate designer.
  • The event processing component will receive an EventCreated event and update the query database with the data contained in the event (i.e., the event identifier and its name).
  • A domain can register and send a UserWasInvitedToEvent event to event handlers.
  • Event processors collect UserWasInvitedToEvent and update the query store with the necessary reporting data.
  • Another event handling component will also receive a UserWasInvitedToEvent event. This process can access the query database and discard all the data needed to send the email.

A query database is nothing more than a reporting database, so you might even have a specific table that stores all the data needed for email in one place.

To organize several different events into one handler (provided that the events can be processed in a different order at different times), you can use the Saga concept in your message bus. NServiceBus is an example of a messaging bus that supports Saga . See also this StackOverflow question: Delayed NServiceBus message processing .

+6
source share

All Articles