Inter-Aggregate Comunicazione in CQRS + DDD + Evento Sourcing

Question

Come dovrebbe separare aggregato radici (AR) comunicano tra loro in un ambiente costruito su principi DDD utilizzando un aggregato di back-end evento di origine?

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

In DDD, mi avrebbe tenuto riferimenti al Booking in Person, e Person in Facility. Tuttavia, quando si generano gli eventi per l'utilizzo in eventi-sourcing Credo che il tentativo di gestire la deserializzazione evento dal back-end sarebbe diventato proibitivo. Pertanto, ho preso solo in possesso di riferimenti agli ID unico a base di oggetti di valore. Questo porta in primo piano un nuovo problema, tuttavia, quando un metodo su un AR ha bisogno di chiamare un altro metodo su un altro AR - come si fa a gestire questa situazione? Colpite il repository di origine evento dal AR dominio?

Qual è il caso d'uso generale, in questo scenario? Am I affrontare questo tutto sbagliato?

Answer 1

frontiere Aggregate Root definire un contorno di coerenza. All'interno dell'aggregato, la coerenza è garantita. Fuori ... non lo è. Quindi non si dovrebbe avere operazioni che si estende su diversi aggregati e devono essere coerenti. Se avete bisogno di una transazione che si estende due aggregati, si dovrebbe rivedere i confini aggregati.

Per le cose che accadono al di fuori l'aggregato si dovrebbe avere un gestore di eventi che invierà un comando per altri aggregati. Se la logica delle azioni tra gli aggregati è più complicato, è possibile definire un processo, una macchina a stati che ascoltare gli eventi e inviare comandi ad aggregati. I processi possono essere utilizzati per definire in esecuzione lungo transazioni (con compensazione invece di rollback), o prendere decisioni sulla base di ciò che sta accadendo nel sistema su larga scala (anche tra i contesti limitati).

Answer 2

Quando si utilizza Evento Sourcing e CQRS l'elegante (almeno a mio parere) modo la maggior parte di comunicazione inter-AR è di messaggistica. Potete guardare Ncqrs progetto (sarà più facile se sei un ragazzo NET), in particolare ' Messaggi' ramo. L'idea è, RA implementare l'interfaccia IMessageHandler per ogni tipo di messaggio che gestiscono e AR classe base metodo espone Invia per l'invio di messaggi lì. Mediante questo client API può invocare comportamento del modello e il modello stesso può comunicare (tra RA).