CQRS - Quando inviare un messaggio di conferma?

Question

Esempio: Le regole aziendali indicano che il cliente deve ricevere un messaggio di conferma (e-mail o simile) quando viene effettuato un ordine.

Diciamo che uno NewOrderRegisteredEvent viene inviato dal dominio ed è raccolto da un listener di eventi che invia il messaggio di conferma. Quando ciò viene fatto, un altro gestore di eventi genera un'eccezione o qualcos'altro va storto e l'unità di lavoro viene ripristinata. Ora abbiamo inviato all'utente un messaggio di conferma per qualcosa che è stato ripristinato.

Qual è il modo "cqrs" per risolvere problemi come questo in cui si vuole fare qualcosa dopo aver commesso un'unità di lavoro? Un altro fattore complicante è la ripetizione degli eventi. Non voglio che i vecchi messaggi di conferma vengano nuovamente inviati ogni volta che rieseguo gli eventi registrati per creare una nuova vista/proiezione.

La mia migliore teoria fino ad ora: ho appena iniziato a esaminare l'affascinante mondo dei cqrs e mi chiedevo se questo sarebbe stato implementato come una saga? Se una saga è come una macchina a stati in cui ogni transizione può avvenire solo una volta, immagino che risolverebbe questo problema? Ho solo un momento difficile visualizzare come questo si adatta insieme con gli eventi del bus di comando e dominio ..

Answer 1

1. Un evento deve verificarsi solo dopo che la transazione è stata completata. Se qualcosa va storto e c'è un rollback, allora l'evento non si è verificato da un punto di vista esterno. Pertanto non dovrebbe essere pubblicato affatto. Anche se un evento OrderRegistrationFailed potrebbe essere pubblicato, se necessario.

2. Non si desidera che la posta venga inviata a meno che il comando non sia stato eseguito correttamente.

   Prima alcuni motivi per cui il gestore di comandi, come proposto in un'altra risposta, sarebbe il posto sbagliato: in alcune circostanze il gestore comandi non sarebbe in grado di stabilire se il comando alla fine riuscirà o meno. Avere che il gestore comandi invoca l'invio di posta metterebbe anche le conoscenze di processo all'interno del gestore comandi, il che interromperà l'SRM e accoppierà troppo strettamente le regole aziendali con il livello dell'applicazione.

   La posta deve essere inviata dopo il fatto, ad esempio da un gestore eventi.

   Per impedire a questo gestore di sparare durante la riproduzione, non è possibile registrarlo. Funziona in modo simile a come testate la vostra applicazione. Si registrano solo i gestori effettivamente necessari.

   sistema
   • Produzione -> registrare tutti i gestori di eventi
   • Test -> registrare solo i gestori di eventi testati
   • Replay -> registrare solo i gestori di proiezione/denormalizzazione

altro - ancor più sciolto, anche se un po 'più complesso, la possibilità sarebbe quella di avere un Saga gestire lo NewOrderRegisteredEvent e inviare un comando SendMail all'approccio contesto limitato e opaco (grazie, Yves Reynhout, per averlo indicato nei commenti della domanda).

Answer 2

Ci sono due possibili soluzioni

1) La pubblicazione della manifestazione e la gestione della manifestazione (ad esempio l'e-mail) fanno parte di un'unica transazione. In questo caso, il framework delle transazioni si prende cura di te per te. Se l'email non riesce, l'evento viene ripristinato. Probabilmente riproverai il comando. Questo è concettualmente pulito e facile da pensare. Nessun evento è finito di pubblicare fino a quando tutti quelli che hanno qualcosa da dire a riguardo hanno espresso la loro opinione. Tuttavia, in pratica, questo può essere doloroso, in quanto comporta in genere transazioni distribuite. Questi sono difficili da trovare. Il tuo client di posta elettronica può iscriversi alla stessa transazione del database che ospita i tuoi eventi?

2) La pubblicazione dell'evento è transazionale, ma i gestori di eventi gestiscono ciascuna le transazioni a modo loro. Il gestore eventi che invia le email potrebbe tenere traccia di quali eventi ha visto. Se si arrestasse in modo anomalo, richiederebbe vecchi eventi ed elaborarli. Potresti prendere una decisione aziendale su quanto sarebbe importante se le persone manchino o duplichino email. (Per le transazioni relative al denaro, probabilmente la risposta non dovrebbe essere consentita.)

La soluzione (2) è in genere ciò che viene promosso nei cerchi DDD/CQRS in quanto è la soluzione più sciolta. La soluzione (1) è abbastanza pratica in un piccolo sistema in cui l'archivio degli eventi e le proiezioni si trovano in un unico database e le proiezioni non cambiano spesso. La soluzione (2) consente a una varietà di gestori di eventi di funzionare a modo loro. La soluzione (1) può causare un sacco di problemi non sovrapposti per diventare entagled. In questo caso le regole aziendali dell'ordine non vengono completate fino a quando non vengono prese in considerazione le molte cose bizzarre che si verificano nell'e-mailing. Per prima cosa, potrebbe rallentarti un po '.

Se l'invio dell'e-mail era più interessante di "ha visto l'evento, ha inviato l'e-mail", allora hai ragione, potresti avere una saga o un flusso di lavoro nelle tue mani. L'e-mail in operazioni di grandi dimensioni è spesso un sistema complesso a sé stante che è improbabile che tu debba implementare molto di. Devi solo essere sicuro di mettere la tua e-mail in una coda di richieste di qualche tipo (usando approccio (2)), e il sistema email probabilmente farà tentativi/batch/evitamento dello spam/lavoro durante la notte/ecc.