2012-04-18 4 views
5

Sto lavorando su un sistema CQRS/event store. Al momento, il pattern che utilizzo è che i comandi siano sincroni. Cioè, l'interfaccia utente non mostra un'operazione come completata fino a quando il comando non è completo, e il successo/fallimento è mostrato all'utente. Durante l'esecuzione dei comandi, tutti gli eventi generati (ad es., L'azione X si è verificata sulla radice aggregata Y) sono archiviati in una memoria duratura.Quali sono i vantaggi dell'archiviazione dei comandi in un sistema CQRS/ES?

Tutte le descrizioni di CQRS di cui ho letto la memoria di comando dell'attrezzo. Mi chiedo se questo è necessario nella mia situazione.

Un'altra nota: ci sono molte azioni di tipo comando a lungo termine, quindi ho suddiviso le operazioni in un comando che genera eventi e gli eventi a loro volta emettono più comandi. I comandi sono idempotenti, in base allo stato della radice aggregata. Non so come questo potrebbe avere un impatto sulla risposta, ma vale la pena segnalarlo.

Grazie, Erick

+0

Potrebbe fornire alcuni esempi di implementazione che memorizzano i comandi? La maggior parte degli esempi che ho visto memorizza solo gli eventi prodotti come risultato dei comandi. –

+0

Non ho alcun framework, ma CQRS senza l'event sourcing dei comandi dei record per la riproduzione, almeno dalla mia comprensione. –

+0

Sono un po 'preoccupato per la sicurezza. Che cosa hai intenzione di fare con comandi come ChangeUserPassword che contiene una password in chiaro? – Kimble

risposta

6
  1. regressione test Dopo ogni dev iterazione si può afferrare registro comando da ambiente di produzione, ri-eseguire e confrontare flusso di eventi realizzato con uno sulla produzione. Se sono diversi, hai una regressione nella tua logica.

  2. Visualizzazione e analisi del flusso di messaggi.

4

Gli esempi di Cqrs che ho visto senza approvvigionamento manifestazione sono soliti database relazionali che memorizzano lo stato del sistema, piuttosto che eventi che mostrano come lo stato dei dati è nata. "Command sourcing" è un nuovo concetto per me e non sembra corretto dato che i gestori di comandi possono cambiare nel tempo. Eventuali modifiche alla logica dei gestori di comandi probabilmente comporterebbero il mancato funzionamento dei comandi durante la riproduzione. La riproduzione di eventi non presenta questo problema poiché le proprietà degli oggetti sono impostate direttamente.

+0

Questo ha senso - grazie! –