Con un po’ di ritardo rispetto al desiderata, ecco la risposta ad alcune osservazioni/domande che sono state fatte al post precedente:
Per semplicità il domain event che notificava l’avvenuto cambio di sede operativa riportava solo un subset di informazioni
Dato che un domain event deve essere il più autoconsistente possibile, ovviamente, deve contenere tutte le informazioni che identificano e determinano il cambio di stato dell’aggregate root che lo notifica. Volendo fare i “pignoli”, quindi, la corretta e completa implementazione di tale domain event potrebbe essere la presente:
In questo modo, l’handler (o i molteplici handler) deputati a gestire l’evento, hanno sia l’informazione semantica di ciò che è successo (“sede operativa modificata”) sia le informazioni relative al cambio di stato.
La seconda questione “aperta” dal post precedente è relativa all’ “ordine delle operazioni”: quando un evento viene notificato l’aggregate è già stato persistito? Quindi, qualora dovessi averne bisogno, avrei la versione aggiornata oppure si corre il rischio di utilizzare una versione “vecchia”? La risposta è un po’ articolata, quindi partiamo dalla versione semplice: sì, assolutamente sì. Lo scopo dei domain event è quello di notificare un cambio di stato di un aggregate root, quindi il cambio di stato deve essere già avvenuto e, qualora necessario, persistito, altrimenti rischiamo di utilizzare una porzione di sistema non “consistente”.
Quando parliamo di cambio di stato di un aggregate root, parliamo del “domain model” vero e proprio, della parte che reagisce al “C” di CQRS. Questa parte è il cuore del nostro sistema e non possiamo correre il rischio che sia “eventualmente consistente”. Tutto diverso invece sull’altra sponda: la parte il lettura, “R” per gli amici. Lì sì possiamo permetterci, a seconda del contesto in cui siamo, di avere un delay nell’aggiornamento del dato che andiamo a leggere. Da questo versante non dipendono logiche di business, ma solo di visualizzazione.
Spingendosi un po’ oltre, e abbracciando EventSourcing al 100% ci accorgeremmo che il problema in oggetto non si pone più in quanto lo snapshot dello stato dell’aggregate non ha più motivo di esistere e una volta “persistito” il domain event abbiamo la possibilità di ricostruire la nostra porzione di sistema al massimo dettaglio, garantendo quindi il massimo grado di consistenza possibile.
Dal mio punto di vista quindi gli handler devono essere sempre asincroni, perchè ciò permette al sistema di essere veramente “distribuito” e poco “accoppiato”. Ovviamente per poter sfruttare l’asincronicità degli handler bisogna garantire quanto sopra.
Per chi si approccia o si sta approcciando ad un sistema ad eventi, come faceva notare GianMaria, è forte la sensazione di dispersione della logica di business tra un handler e l’altro. Ok, non preoccupatevi, quando avete questa percezione siete sulla strada giusta 🙂 Ma bisogna introdurre un nuovo componente: la saga.
Ma per tutto questo, come fa il buon Ayende (e qualcuno riderà sotto i baffi)…vi rimando ai prossimi post 🙂
