Ecco uno scenario.
Sto costruendo QueueUnderflow , un sito di Q & community-edited per persone che non hanno ancora compreso le basi delle strutture dati. Ai miei utenti non piace quando le persone modificano i loro post così, perché voglio incoraggiare il maggior numero possibile di conflitti, voglio inviare notifiche via email ogni volta che il post di un utente viene modificato in modo che possa accedere e insultare l'editor.
Sto sperimentando con CQRS. Non sto utilizzando il sourcing di eventi e ho un singolo data store ma I am utilizzo di gestori di eventi per gestire la persistenza di eventuali cambiamenti di stato.
In una normale applicazione N-Tier / CRUD questo potrebbe essere attivato da una facciata di un'applicazione o da un livello di servizio. Nella mia architettura CQRS, posso vedere alcune opzioni:
- Il gestore di eventi: mi piace questa idea perché sembra che l'invio di un'e-mail di notifica sia una preoccupazione che potrebbe risiedere in una parte indipendente del sistema che desidera ascoltare il momento opportuno per inviare una e-mail e quindi inviarlo, trasparente al resto del sistema. Non mi piace questa idea perché Greg Young (ragionevolmente) sottolinea nei suoi video che se io avessi per introdurre il sourcing di eventi, ciò avrebbe comportato l'invio di email di notifica potenzialmente molte volte.
- Il gestore di comandi: questo è un approccio più esplicito che ha ancora senso per me; tuttavia, sembra che il consenso generale sia che i gestori di comandi dovrebbero essere solo per il coordinamento di oggetti di dominio e non per il comportamento direttamente performante.
- Il dominio: sembra sbagliato. L'invio di e-mail di notifica è una preoccupazione dell'applicazione, non tanto del dominio che riguarda principalmente la logica di business.
- Il livello di presentazione (o potenzialmente una facciata di un'applicazione intermedia che passa semplicemente un comando al suo gestore ed esegue altre azioni specifiche dell'applicazione come l'invio di notifiche).
La domanda è: quale parte della mia architettura è responsabile per l'invio di e-mail?