CQRS e notifica e-mail

Question

Leggendo su CQRS si parla molto di notifiche via e-mail - mi chiedo da dove ottenere i dati. Immagina un senario in cui un utente invita altri utenti a un evento. Per informare un utente che è stato invitato a un evento, gli viene inviata un'email.

I passi concreti potrebbero andare come questo:

1. Un comando CreateEvent con una collezione di associato agli utenti di invitare, vengono ricevuti dal server.
2. Viene creato un nuovo aggregato Meeting e viene chiamato un metodo InviteUser per ogni utente che deve essere invitato.
3. Ogni volta che un utente viene invitato a un evento, viene generato un evento di dominio UserWasInvitedToEvent.
4. Un mittente di notifica e-mail raccoglie l'evento di dominio e invia l'e-mail di notifica.

Ora la mia domanda è questa: dove devo andare per informazioni da includere nell'e-mail?

Dire che voglio includere una descrizione dell'evento e il nome dell'utente. Dato che questo è CQRS non riesco a ottenerlo attraverso il mio modello di dominio; Tutte le proprietà degli oggetti del dominio sono private! Dovrei quindi interrogare il lato di lettura? O forse spostare la notifica e-mail su un servizio diverso interamente?

Answer 1

In CQRS, si separa il comando dal lato della query. Dovrai sempre andare sul lato della query per ottenere dati per un determinato gestore di eventi. Il database di scrittura sarà un database separato che contiene i dati necessari per la creazione degli oggetti del dominio e non sarà ottimizzato per le letture, ma per le scritture.

1. Il dominio deve registrarsi e inviare un evento EventCreated ai gestori di eventi/processori. Questo potrebbe essere generato dal costruttore dell'aggregato Meeting.
2. Il componente di elaborazione eventi rileva l'evento EventCreated e aggiorna il database di query con i dati contenuti nell'evento (ad esempio, l'ID dell'evento e il suo nome).
3. Il dominio potrebbe registrare e inviare un evento UserWasInvitedToEvent ai processori evento.
4. I processori di eventi prelevano lo UserWasInvitedToEvent e aggiornano l'archivio di query con tutti i dati di report necessari.
5. Un altro componente di elaborazione eventi rileva anche l'evento UserWasInvitedToEvent. Questo processo potrebbe avere accesso al database delle query e recuperare tutti i dati necessari per l'invio dell'email.

Il database di query non è altro che un database di report, pertanto è possibile avere anche una tabella specifica che memorizza tutti i dati necessari per l'e-mail in un'unica posizione.

Per orchestrare diversi eventi in un singolo gestore (supponendo che gli eventi possano essere elaborati in un ordine diverso in momenti diversi), è possibile utilizzare il concetto di Saga nel proprio bus di messaggistica. NServiceBus è un esempio di bus di messaggistica che è supports Saga's. Vedi anche questa domanda StackOverflow: NServiceBus Delayed Message Processing.