Comunicazione intergrega in CQRS + DDD + Event Sourcing

Question

In che modo separare aggregate roots (AR) comunicare tra loro in un ambiente basato sui principi DDD utilizzando un back-end aggregato basato su eventi?

Ad esempio, ho una radice aggregata Facility aggregata (AR) che ha un metodo factory responsabile della creazione di un AR Booking. Il Booking è una combinazione sensibile al tempo di un AR e un AR Facility. Un Person può essere prenotato solo in un singolo Facility.

In DDD, avrei mantenuto i riferimenti allo Booking in Person e Person in Facility. Tuttavia, quando si generano eventi da utilizzare in event-sourcing, penso che provare a gestire la deserializzazione degli eventi dal back-end diventerebbe proibitivo. Pertanto, ho deciso di mantenere solo i riferimenti all'id valore univoco basato su oggetti. Ciò solleva un nuovo problema, tuttavia, quando un metodo su un AR deve chiamare un altro metodo su un altro AR - come gestisci quella situazione? Colpisci il repository dell'origine dell'evento dal dominio AR?

Qual è il caso di utilizzo generale in questo scenario? Mi sto avvicinando a questo tutto sbagliato?

Answer 1

I limiti di radice aggregati definiscono un limite di coerenza. All'interno dell'aggregato, la coerenza è garantita. Al di fuori ... non lo è. Quindi non dovresti avere operazioni che si estendono su più aggregati e che devono essere coerenti. Se è necessaria una transazione che si estende su due aggregati, è necessario rivedere i propri limiti aggregati.

Per cose che accadono al di fuori dell'aggregato si dovrebbe avere un gestore di eventi che invierà un comando ad altri aggregati. Se la logica delle azioni tra aggregati è più complicata, è possibile definire un processo, una macchina a stati che ascolterà gli eventi e invierà comandi agli aggregati. I processi possono essere utilizzati per definire transazioni di lunga durata (con compensazione anziché rollback) o prendere decisioni aziendali in base a ciò che accade nel sistema su larga scala (anche tra contesti limitati).

Answer 2

Quando si utilizza Event Sourcing e CQRS il modo più elegante (almeno a mio avviso) di comunicazione inter-AR è la messaggistica. Puoi guardare il progetto Ncqrs (sarà più facile se sei un utente .NET), in particolare il ramo 'Messaggi'. L'idea è che le AR implementano l'interfaccia IMessageHandler per ogni tipo di messaggio che gestiscono e la classe base AR espone il metodo Send per l'invio di messaggi. Mediante questa API i client possono richiamare il comportamento del modello e il modello stesso può comunicare (tra AR).