Sourcing e persistenza degli eventi

Beneficerai maggiormente del sourcing degli eventi quando decidi di cambiare anche l'architettura del tuo sistema. Andare verso un'architettura in stile CQRS combinata con DDD porterà i veri benefici di un evento di sourcing, almeno secondo me.

Costruire un negozio di eventi che si comporta bene nei grandi sistemi non è un compito facile. La riproduzione di tutti i dati potrebbe essere molto costosa, dipende molto dalla quantità di dati che devono essere riprodotti. Ma ci sono tecniche che potrebbero aiutarti con questo, uno di questi è il concetto di un'istantanea. Il replay è fatto solo da un certo punto in avanti. I vantaggi che un negozio di eventi porta nel tuo sistema sono inestimabili. Avere tutto ciò che è successo nel tuo sistema può essere riprodotto, tutti i dati in ogni momento sono una grande cosa. Pensa all'analisi, alla riproduzione dei bug, alle statistiche.

Ci sono molti grandi negozi di eventi, l'ultimo è stato appena pubblicato ieri Event Store 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 considerando le esigenze di query dell'applicazione e dei client.

Ho scritto un articolo dettagliato su quali sono i vantaggi e su come si presenta un'architettura CQRS combinata con l'event sourcing. Puoi verificarlo CQRS, eventi di dominio e revisione DDD .

Con Event Sourcing la domanda principale è "qual è il tuo libro dei record".

Se il tuo libro dei record è il tuo flusso di eventi, allora non avrai problemi. Se il tuo libro dei record è il tuo "modello di entità", i problemi inizieranno a succedere ovunque. Parte di questo è che puoi dire "se ho 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 dei record.

È anche importante ricordare che la maggior parte delle persone che usano il sourcing di eventi usa un modello di lettura. Questo modello è usato per interrogare i dati. Tuttavia, è più probabile che assomigli a un modello 1nf piuttosto che a un modello di entità 3nf. Riproducono solo gli eventi per recuperare gli stati degli aggregati per determinare se le scritture devono essere consentite.

I can still have a DB with all entities, right? Or should the events be replayed every time the application is started to get the latest version of each entity in the memory?

La risposta dipende dai requisiti dell'applicazione. L'ho visto fatto in entrambi i modi.

Un pacchetto software di grande successo per piccole aziende contabili legge il suo log CQRS ogni volta all'avvio. La quantità di dati grezzi era relativamente piccola, quindi il tempo di avvio era inferiore a un minuto anche nei computer più lenti. Hanno fatto il CQRS per più di un decennio prima che la pratica diventasse popolare. Sapevano che stavano facendo qualcosa di buono quando si sono resi conto che potevano aggiornare i loro dati client ancora e ancora senza incorrere in problemi che vedevano con i loro sistemi più grandi.

Nei sistemi con volumi maggiori di dati e / o sistemi che si basano sulla funzionalità RDBMS per implementare il lato della query, si dispone di un database per la "visualizzazione corrente" dei dati di origine dell'evento (è possibile avere anche più visualizzazioni di questo tipo). Il vantaggio di questo approccio è che ti consente di creare il lato query utilizzando le tecnologie familiari.