CQRS: come gestire le nuove tabelle di report (o: come importare TUTTA la cronologia dall'archivio eventi)

Ho studiato alcune implementazioni di esempio CQRS (Java/.Net) che utilizzano il sourcing di eventi come archivio eventi e un semplice (No) SQL memorizza come 'archivio rapporti'.CQRS: come gestire le nuove tabelle di report (o: come importare TUTTA la cronologia dall'archivio eventi)

Sembra tutto a posto, ma mi sembra che manchi qualcosa in tutte le implementazioni di esempio.

Come gestire l'aggiunta di nuovi archivi/schermate di report, dopo che un'applicazione è entrata in produzione? e come importare i dati (più recenti) esistenti dall'archivio eventi al nuovo archivio report?

Ie:

immaginare una base DDD/CQRS guidati applicazione CRM. Ogni schermata (visualizza realmente) ha il proprio archivio di report strutturati (una tabella SQL). Tutte queste visualizzazioni vengono aggiornate mediante gestori che ascoltano gli eventi del dominio (CustomerCreated/CustomerHasMoved, ecc.).

Una funzione del CRM è che può registrare le chiamate telefoniche (evento PhoneCallLogged). A causa dei limiti di tempo, abbiamo implementato solo la registrazione delle chiamate telefoniche in V1 del CRM (visualizzazione e segnalazione di chi ha gestito quale telefonata verrà implementata in V2)

Dopo un periodo di rodaggio, vogliamo implementare il ' segnalazione di chiamate telefoniche registrate per cliente e rappresentante commerciale.

quindi abbiamo bisogno di aggiungere alcune schermate (vista) e le tabelle dei rapporti di sostegno (nel negozio report) e riempirlo con i dati già raccolti nello Store Event ...

è lì che mi si blocca guardando i campioni che ho studiato. Non gestiscono l'importazione dei dati esistenti (cronologia) dall'archivio eventi a un (nuovo) archivio rapporti.

Tutti gli esempi di EventRepository (DomainRepository) hanno solo un metodo 'GetById' e 'Aggiungi', non supportano il recupero di TUTTE le radici aggregate una sola volta per riempire una nuova tabella di report.

Senza questa importazione iniziale di dati, le nuove schermate vengono aggiornate solo per gli eventi appena verificati. Non per le chiamate telefoniche già registrate (perché non c'era nessun listener di report per l'evento PhoneCallLogged)

Eventuali suggerimenti, consigli?

Grazie in anticipo,

Remco

fonte

2010-04-01 Remco Ros

È rieseguire il gestore del registro eventi esistente (ad esempio, si gioca i vecchi eventi attraverso il nuovo gestore di eventi)

si consideri ad esempio .. Hai un sacco di PhoneCallLoggedEvents nel tuo registro eventi. Porta i tuoi nuovi Handle e suona tutti i vecchi eventi. È quindi come se fosse sempre stato in esecuzione e continuerà a elaborare tutti i nuovi eventi che arrivano.

Cheers,

Greg

fonte

2010-04-14 13:56:01

Quindi, in pratica è necessario integrare una sorta di one-time corridore evento (rapporto impor t) nel processo di distribuzione? –

E avrai bisogno dell'accesso "Query" al negozio degli eventi: store.GetAllEvents (); Questo sembra contro-intuitivo perché (come ho detto) Tutte le implementazioni di un EventStore che ho visto (entrambi .net/java) non consentono tale accesso in lettura ... –

Di solito le implementazioni fornite contengono solo ciò che è necessario in fase di runtime, ma non ciò che è necessario per la manutenzione. – thinkbeforecoding

Il 'EventRepository' contiene solo questi metodi perché è solo bisogno di loro produzione.

Quando si aggiunge una nuova denormalizzazione per il reporting, è possibile inviare tutti gli eventi dall'inizio al gestore.

È possibile farlo sul tuo sito di sviluppo in questo modo:

Caricare il registro eventi per il sito dev
Invia tutti gli eventi al gestore denormalizzazione
Spostare la nuova visualizzazione + gestore per il vostro sito di produzione
eventi Run accaduti inbetween
Ora si è pronti

fonte

2010-04-14 14:05:59 thinkbeforecoding

Questo non è davvero fattibile nel modo in cui descrivi. Non abbiamo accesso ai dati di produzione (eventi). Ma in base alla risposta di tuo e di Greg, ora vedo che avrai bisogno di una sorta di componente di importazione una tantum (Event Runner) che viene eseguito una volta sola quando si distribuisce il nuovo gestore alla produzione. –

Cosa ti impedisce di ottenere gli eventi? Una volta accaduto, non cambieranno mai, quindi non c'è alcun rischio di fare una copia. Ma in ogni caso, avrai bisogno di un componente (o processo) che legge tutti gli eventi e chiama il gestore. – thinkbeforecoding

Per esempio in Axon quadro, questo può essere fatto attraverso:

JdbcEventStore eventStore = ...; 

ReplayingCluster replayingCluster = new ReplayingCluster(
      new SimpleCluster("replaying"), 
      eventStore, 
      new NoTransactionManager(), 
      0, 
      new BackloggingIncomingMessageHandler()); 

replayingCluster.startReplay();

evento di replay è una zona che non è completamente documentato e manca di attrezzature maturo, ma qui ci sono alcuni punti di partenza:

fonte

2016-01-23 18:07:06 AlexO

CQRS: come gestire le nuove tabelle di report (o: come importare TUTTA la cronologia dall'archivio eventi)

risposta

Problemi correlati