Event Sourcing, saghe, bus ed eventuale consistenza

Question

Event Sourcing, saghe, bus ed eventuale consistenza

#1 da (5 voti)

5

Attualmente sto imparando su Event Sourcing tramite il libro Microsoft .NET - Architecting Applications for the Enterprise . L'individuazione degli eventi è, secondo le mie parole, un modello architettonico di memorizzazione di "eventi" anziché di "entità attuali". Le entità attuali possono essere create eseguendo il ciclo sugli eventi che appartengono ad esso.

Il problema delle prestazioni di creazione di entità attuali può essere mitigato creando una memoria aggiuntiva in cui periodicamente le entità correnti sono "istantanee" (create dall'istantanea precedente e dagli eventi successivi).

Nel libro l'architettura che appartiene a Event Source è configurata come segue:

Qui tutti gli eventi (correlati a una partita di pallanuoto) sono memorizzati in un negozio RavenDB NoSQL. Vediamo anche un autobus per tenere traccia degli eventi e di una saga che appartiene a gruppi di eventi.

Ho alcune domande su Event Sourcing (ho deciso di chiedere a tutti in una volta poiché tutte le domande riguardano la descrizione nel libro):

Mi chiedo in che modo questi eventi verranno archiviati. Posso immaginare che i dati degli eventi possono cambiare nel tempo (proprietà extra, nuovi nomi di eventi) e che gli eventi devono essere facilmente correlati tra loro e se stessi. In che modo l'attuale struttura del database e il codice di accesso ai dati sembrano facilitare il cambiamento e il recupero dei dati?
Cos'è una saga? Perché si chiama una saga? Sono persistenti e se sì, come?
Come funziona un autobus? Quali sono i vantaggi rispetto alla semplice scrittura di eventi direttamente in un negozio di eventi?
Nell'architettura di cui sopra in cui i comandi e le query sono separati (CQRS) e i comandi sono implementati utilizzando Event Sourcing mentre le query vengono lette dall'istantanea, cosa succede quando i dati devono essere visualizzati durante l'avvio di un comando? (Ad esempio, mostrare i dati del conto bancario mentre un utente desidera effettuare un deposito, sulla base di questi dati.) Come, in pratica, ci assicuriamo che i dati visualizzati siano aggiornati?

architecture architectural-patterns cqrs eventual-consistency event-sourcing

posta Erwin Rooijakkers 29.08.2015 - 17:38

fonte

1 risposta

Leggi altre domande sui tag architecture architectural-patterns cqrs eventual-consistency event-sourcing

Mappatura dei modelli di dominio su ViewModel È razionale convertire protobuf in json per inviarlo a un server web?

score 5 · Accepted Answer

Archiviazione eventi

La memorizzazione degli eventi dipenderà dall'applicazione, ma è molto più semplice se si utilizza una memoria flessibile per i propri eventi (quindi un DB NoSQL, JSON o XML). Il modo in cui gestisci gli aggiornamenti dipenderà da diversi fattori che devi tenere in considerazione, come i requisiti per la disponibilità e i tempi per gli aggiornamenti, la quantità di eventi, ecc ...

Aggiorna i tuoi eventi quando l'applicazione si aggiorna: come parte della distribuzione di una nuova applicazione, aggiorna tutti gli eventi precedenti al nuovo schema
Versione dei tuoi eventi: hai un id della versione sul tuo evento. Quando un evento viene letto dal database, una parte di codice sa come "aggiornare" gli eventi precedenti alla struttura corrente. Come la prima opzione, ma fondamentalmente "su richiesta"
Elimina i tuoi vecchi eventi: quando la tua applicazione si aggiorna, crea un'istantanea di tutte le entità e butta via (o archivia) i vecchi eventi.
Non buttare mai via vecchi eventi: in pratica mantieni "PurchaseOrder" per sempre. Quando hai bisogno di un altro campo, utilizza un nuovo evento come "PurchaseOrderWithCouponCode".

della Saga

Una saga è fondamentalmente un evento di lunga data ridotto a pezzi. Ciò potrebbe essere dovuto a diversi motivi: potrebbe essere perché si desidera un'azione che si traduce in più eventi gestiti in parallelo per evitare il blocco con una transazione, poiché è necessario coordinare diversi sistemi esterni o perché è necessario coordinare con gli eventi che attraversa un contesto limitato. È necessario persisterli per questo motivo: una saga può essere avviata, lanciare alcuni eventi e in alcuni punti non deterministici può essere necessario riprendere avviando più eventi. Udi Dahan ha una buona introduzione su questo.

Bus dei messaggi

C'è molto che si può dire sugli autobus. Essi estrapolano gran parte dell'archiviazione degli eventi e possono gestire scenari più complicati, ad esempio quando si hanno più applicazioni che devono lavorare con l'archivio eventi. Per le piccole applicazioni puoi scrivere direttamente nel negozio degli eventi (e il codice che farebbe questo potrebbe essere considerato un bus ...)

Dati aggiornati

Risposta breve: non lo fai. Il sourcing di eventi funziona su questo in molti modi perché sei "alla fine coerente". In questo esempio, potresti semplicemente visualizzare un messaggio agli utenti che potrebbero essere necessari fino a dieci minuti affinché i depositi vengano visualizzati ...