Sono sulla mia strada per creare un'applicazione con 4 contesti limitati usando CQRS & sourcing di eventi.
Per fare in modo che questi contesti limitati parlassero tra loro stavo pensando di usare Rabbit MQ.
I miei requisiti sono i seguenti:
- Il contesto limitato non deve conoscersi l'un l'altro
- Il contesto limitato non deve essere ostacolato se l'altro contesto limitato è inattivo o se rabbitMQ è inattivo
- Se un contesto limitato non è disponibile i messaggi, che dovrebbe ricevere, devono attendere pazientemente il suo ritorno cioè: ogni evento pubblicato deve essere inoltrato almeno una volta a tutti i bc interessati.
Pertanto, stavo pensando di fare in modo che ognuno di essi facesse riferimento a una coda: BandMasterQueue e lo crea se non lo è.
Quando si produce un evento, l'archivio eventi lo memorizza e la sua spedizione consiste di due passaggi:
- proietta su se stesso questo evento per ogni piccola proiezione. Ogni proiezione ha una piccola serie di eventi già proiettati per garantire l'idempotenza per un certo periodo di tempo.
- pubblica questo evento sulla coda BandMasterQueue
se fallirebbe nel passaggio 2 a causa della mancanza di un conigliomq, allora mi aspetto che il mio negozio di eventi riproverà a inviare il messaggio al RabbitMQ dopo qualche tempo (non proprio però proprio su questa parte, devo dire ...)
Il "contesto limitato" di bandMaster è in grado di riconoscere ogni BC che si prende cura di lui. È lui che legge BandMasterQueue e decide quali eventi sono pubblici e quali no. È anche responsabile della gestione delle "saghe" e può inviare azioni correttive a ogni bc.
Per fare ciò, comunicherà con ogni contesto limitato usando la coda dedicata del contesto limitato e lo creerà se non esce.
Ogni BC è legato a questa coda specifica e aggiunge l'evento proveniente dall'esterno nel proprio archivio eventi e successivamente lo proietta sulla propria proiezione.
Questa "architettura" dovrebbe funzionare o vedi qualche grosso difetto in essa?