Sto leggendo sull'approvvigionamento di eventi e ho una domanda sulla persistenza.
Posso ancora avere un DB con tutte le entità, giusto? O gli eventi devono essere riprodotti ogni volta che l'applicazione viene avviata per ottenere l'ultima versione di ogni entità in memoria? Sembra uno spreco su sistemi più grandi (come in una grande quantità di dati)?
Il punto con l'approvvigionamento di eventi è che posso riprodurre gli eventi per popolare un archivio dati, se necessario? (o analizza i dati)
Risposte:
Trarrai maggiori benefici dall'approvvigionamento di eventi quando deciderai di cambiare anche l'architettura del tuo sistema. Andare verso un'architettura in stile CQRS combinata con DDD farà emergere i veri benefici di un evento di provenienza, almeno secondo me.
Costruire un negozio di eventi che si comporta bene in sistemi di grandi dimensioni non è davvero un compito facile. La riproduzione di tutti i dati potrebbe essere davvero costosa, dipende molto dalla quantità di dati che devono essere riprodotti. Ma ci sono tecniche che potrebbero aiutarti in questo, uno dei quali è il concetto di un'istantanea. Il replay viene eseguito solo da un certo punto in avanti. I vantaggi che un negozio di eventi porta nel tuo sistema sono inestimabili. Avendo tutto ciò che è accaduto nel tuo sistema riproducibile, tutti i dati in ogni momento sono grandiosi. Pensa all'analisi, alla riproduzione dei bug, alle statistiche.
Ci sono molti grandi negozi di eventi, l'ultimo è stato appena rilasciato ieri Store di eventi e sembra davvero buono.
Il database tradizionale può essere conservato per la parte di query del sistema per creare DTO con i dati richiesti. Questo database può essere organizzato e ottimizzato tenendo conto delle esigenze di query dell'applicazione e dei client.
Ho scritto un articolo dettagliato su quali sono i vantaggi e come appare realmente un'architettura CQRS combinata con il sourcing degli eventi. Puoi verificarlo CQRS, Domain Events e DDD review .
Con Event Sourcing la domanda principale è "qual è il tuo libro dei record".
Se il tuo libro dei record è il tuo flusso di eventi, non avrai problemi. Se il tuo libro dei record è il tuo "modello di entità", allora i problemi inizieranno a verificarsi ovunque. Parte di questo è che puoi dire "se avessi perso il mio modello di entità potrei ricostruirlo dal mio flusso di eventi". Se sei positivo su questa domanda, il tuo registro eventi è il tuo libro di registri.
È anche importante ricordare che la maggior parte delle persone che utilizzano il sourcing di eventi utilizzano un modello di lettura. Questo modello viene utilizzato per l'interrogazione dei dati. Tuttavia, è più probabile che assomigli a un modello 1nf che a un modello entità 3nf. Replay solo gli eventi per recuperare gli stati degli aggregati per determinare se le scritture dovrebbero essere consentite.
Posso ancora avere un DB con tutte le entità, giusto? O gli eventi devono essere riprodotti ogni volta che l'applicazione viene avviata per ottenere l'ultima versione di ogni entità in memoria?
La risposta dipende dai requisiti dell'applicazione. L'ho visto fare in entrambi i modi.
Un pacchetto software di grande successo per le piccole società di contabilità legge il suo registro CQRS ogni volta all'avvio. La quantità di dati grezzi era relativamente piccola, quindi il tempo di avvio era inferiore a un minuto anche sui computer più lenti. Hanno fatto CQRS per più di un decennio prima che la pratica diventasse popolare. Sapevano di aver fatto qualcosa di buono quando si resero conto che potevano aggiornare i dati dei loro clienti ancora e ancora senza incorrere in problemi che vedono con i loro sistemi più grandi.
Nei sistemi con maggiori volumi di dati e / o sistemi che si basano sulla funzionalità RDBMS per l'implementazione del lato query, si dispone di un database per la "vista corrente" dei dati provenienti da eventi (è anche possibile avere più di tali viste). Il vantaggio di questo approccio è che consente di creare il lato query utilizzando le tecnologie familiari.