Come aggiornare un registro eventi in caso di nuovi eventi

Question

Come aggiornare un registro eventi in caso di nuovi eventi

#1 da (1 voti)

2

In CQRS con Event Sourcing, se il dominio corrente manca di una funzionalità, quindi deve essere esteso con un nuovo comando (inviato da una nuova saga) e un evento (inviato dal gestore aggregato di quel comando), come posso distribuire tale funzione su un'applicazione già in esecuzione se il comando non è mai stato inviato prima e quindi anche l'evento non è mai stato parte del registro eventi fino alla distribuzione.

L'evento è essenziale per la corretta inizializzazione di aggregazione, quindi ho bisogno di avere l'evento nel registro eventi per ogni possibile situazione in passato in cui questo comando / evento avrebbe dovuto essere inviato.

Poiché il registro eventi deve essere solo accodato. C'è un modo come aggiungere un evento al flusso di eventi passati se la distribuzione di tale funzionalità lo richiede? Va bene farlo manualmente? O qual è il modo.

Esempio

Per essere più precisi sul mio problema: considera un'applicazione per file system, in cui sono presenti aggregati per file (File) e cartelle (Cartella). Singoli file e cartelle (entrambi chiamati nodi) sono radici aggregate. Non riesco a memorizzare l'intero albero del file system in una singola radice a causa delle prestazioni.

Nella vecchia versione, se creo un nuovo file in una cartella, si tratta di un comando su File aggregate in cui imposto la sua cartella padre (la proprietà dell'aggregato). Ora mi sono reso conto che mi piacerebbe avere una lista di ID dei nodi che contiene una cartella. Questa funzione non faceva parte della versione originale, quindi le cartelle non avevano idea dei nodi che erano stati memorizzati nella cartella.

La mia soluzione era di creare una saga avviata dall'evento NewFileCreated, che avrebbe inviato un nuovo comando AddFileToFolder all'aggregazione della cartella principale. Quel comando applicherebbe un evento (FileAddedToFolder) nella cartella che aggiungerebbe l'ID del file al suo insieme di nodi figli.

Per implementare questa funzione, in cui mi piacerebbe avere gli ID figli corretti in tutte le cartelle, è limitato dall'assenza di questi eventi nel registro eventi originale.

Quale dovrebbe essere il modo di aggiornare il vecchio registro eventi in quel caso?

cqrs event-sourcing

posta redhead 07.11.2015 - 15:39

fonte

1 risposta

Leggi altre domande sui tag cqrs event-sourcing

Come integrare il codice generato modificato nel processo di compilazione? Il modo migliore per scrivere i test delle unità per il middleware HTTP

score 1 · Accepted Answer

Penso che in questo caso invece di aggiungere questo al tuo aggregato, la soluzione migliore sarebbe quella di avere un database locale pienamente coerente per i tuoi aggregati da utilizzare per tenere traccia delle loro relazioni. Potrebbe essere incorporato. Potrebbe essere un negozio chiave / valore o relazionale, o qualunque cosa sia conveniente. Questo non è un modello di visualizzazione alla fine coerente, ma un database separato che è mantenuto coerente con i tuoi aggregati.

In realtà, le relazioni tra i nodi si trovano già negli eventi, non sono solo in una forma utilizzabile per il comando di eliminazione. Un archivio eventi non è un database relazionale e le relazioni sono proibitive per la query. L'uso di un modello di visualizzazione non è abbastanza buono perché alla fine è coerente. Quindi un database locale completamente coerente è il migliore qui fuori. Questo è anche un modo comunemente usato per soddisfare i controlli di unicità (ad es. Indirizzo email) come parte dei comandi di gestione.

È possibile popolare questo database con le relazioni di eventi esistenti (fondamentalmente un denormalizzatore unico che legge gli eventi e aggiorna questo database) durante la distribuzione, quindi è aggiornato quando entra in produzione.

Ogni volta che viene creato un nuovo file in una cartella, questo database viene aggiornato come parte della gestione del comando.

CreateFile folderId -> FileCreated (in folderId)
                       save events
                       update local database for folderId to add child

Quando vai a elaborare il comando delete sulla cartella, hai la possibilità di cercare tutti i sottonodi della cartella da quel database.

Mi domando se l'evento in uscita sia la scelta migliore per questo set di problemi. Non è ottimale per lo scenario qui descritto. Tuttavia, potrebbe valere la pena di usare (e superare problemi come questo) se l'auditabilità è un requisito primario.