Come conservare Sagas con Event Sourcing

Hai due opzioni per eseguire una Saga:

1. In modo sincrono / in-process, ad ogni richiesta, dopo che l'Archivio eventi ha persistito gli eventi, li hai inviati ai Sagas sottoscritti. Questo ha lo svantaggio che quando qualcosa di sbagliato accadrà (cioè il server viene riavviato) perderete eventi.

2. In modo asincrono, come un processo autonomo a esecuzione prolungata che calcola / interroga l'archivio eventi, elabora i nuovi eventi, li riconosce in una memoria persistente e quindi esegue nuovamente il polling / polling. A differenza della prima opzione, quando succede qualcosa di sbagliato, basta riavviare il processo dall'ultimo evento riconosciuto. Questo è il modo preferito, quando possibile.

Da quanto ho capito dai tuoi commenti, "non hai alcun meccanismo per avere un processo in esecuzione continua" così ti rimane l'opzione numero 1.

Una Saga modella un processo di lunga durata; in Event sourcing questo significa un processo che si estende su più eventi. Nel tuo caso, Saga deve raccogliere gli ID aggregati e persisterli come se fosse un'entità . Per questo è possibile utilizzare una persistenza piatta (al contrario di quella basata su eventi), un semplice database NoSQL. Dovresti occuparti della modifica simultanea dell'entità Saga in quanto gli eventi potrebbero venire allo stesso tempo ; per questo è possibile utilizzare operazioni di database di basso livello come addToSet .

Dal punto di vista del DDD, questa entità Saga è in realtà un nuovo tipo di aggregato, ovvero PublishSomeAggregatesToLegacySystemAggregate , che vive forse in un altro contesto Limitato. La Saga reagirà solo agli eventi e invierà comandi a ProcessSomeIDsAggregate , proprio come qualsiasi altra Saga. Questo nuovo Aggregato dovrebbe essere non-event-source. Quindi, quando un Aggregate viene modificato / modificato, la Saga invia un comando AddAggregateToBePublishedToLegacySystem a PublishSomeAggregatesToLegacySystemAggregate . Quando l'evento final viene ricevuto da Saga, invierà il comando PublishTheAggregates .

Devi prestare attenzione a quale tipo di logica hai inserito nella Saga. Dovrebbe contenere solo la logica di coordinamento, non il livello basso come SQL o il codice di accesso al sistema legacy.

"Saga", in questo contesto, viene più comunemente definito "gestore di processi", in parte perché il significato originale della saga era diverso, in parte perché noi facciamo schifo nel nominare le cose.

Il mio punto di partenza raccomandato sui process manager è stato scritto da Rinat Abdullin .

I responsabili di processo sono, in sostanza, comandanti di raccomandazione; dato che so degli eventi A, B e C, raccomando i comandi Y e Z. Sono un dispositivo di mantenimento del libro per tenere traccia del lavoro che dovrebbe essere fatto nel sistema.

Spesso hanno un'espressione interna come macchina di stato.

state = fsm.start()
           .andThen(A)
           .andThen(B)
           .andThen(C)
           .state()

pendingCommands = state.commands()

Come dispositivi per la conservazione dei libri, sono molto simili a "visualizzazioni", nelle cqrs senso. Come le viste, se hai già una cronologia di tutti gli eventi disponibili, puoi riscoprire lo stato in cui si trova un processo.

Ad esempio, potresti immaginare un servizio stand-by, che ha il codice che definisce tutti i tuoi processi. All'avvio, estrae dal tuo archivio eventi l'intera cronologia del mondo, calcola in memoria lo stato di ogni processo gestito e invia i messaggi di comando al modello di dominio. Dopo ogni spunta di orologio, controlla i nuovi messaggi, li legge e invia nuovi messaggi di comando.

Se il servizio va in panico, nessun problema: avvia una nuova copia che ricomincia da capo.

Quindi, in un certo senso, non è necessario scrivere nulla.

(Il che non vuol dire che non dovresti - ci sono dei vantaggi nel sapere quando accadono le cose, ad esempio, o essere in grado di riprodurre il comportamento del sistema di produzione in un ambiente di laboratorio.)