Ripristino dello stato del servizio di scrittura in un sistema Sourced di eventi

Nel sourcing di eventi, il modello di scrittura viene ricostruito dai suoi eventi passati ogni volta che elabora un comando . In DDD, il modello Write è l'aggregato; Mi riferirò come tale. Quindi, l'algoritmo è qualcosa come questo:

1. Il client crea un comando.
2. Il comando arriva a un servizio di applicazione; in alcune architetture questo è chiamato the command handler .
3. Il gestore comandi identifica la classe Aggregate per questo comando; può essere solo uno
4. Il gestore comandi utilizza un repository per caricare gli aggregati
5. Il repository crea un nuovo aggregato vuoto; può utilizzare l'operatore new .
6. Il repository carica tutti i suoi precedenti eventi emessi e li applica uno alla volta e nell'ordine in cui sono stati emessi; ad esempio, Aggregato ha un metodo applyEvent per ogni tipo di evento; Uso una convenzione per denominare i metodi come applyEventShortClassName , uno per ogni classe / tipo di evento; quindi restituisce l'aggregato
7. Il gestore comandi chiama il metodo appropriato su Aggregate; Uso una convenzione e chiamo i metodi come handleCommandShortName(theCommandAsParameter) , ma altri metodi possono essere buoni.
8. Il gestore comandi raccoglie tutti gli eventi emessi da Aggregazione e utilizza il repository per aggiungerli allo stream di eventi per questa istanza Aggregazione. Ogni istanza di Aggregato (ad esempio per ciascun ID) ha un flusso di eventi diverso.
9. Se si verificano eccezioni di concorrenza, l'intero processo viene ritentato dal passaggio 4.

L'algoritmo di cui sopra può differire da un linguaggio di programmazione a un altro, da un'architettura all'altra, ma l'idea principale è la stessa: il modello di scrittura viene ricostruito dal suo flusso di eventi prima di ogni comando.

What I can't find information on is rebuilding the state of the Write Service.

Allo stesso modo - leggi lo stato persistente dal libro dei record.

Il sourcing di eventi non modifica l'idea di base che stiamo memorizzando lo stato che usiamo per ripristinare se le nostre cache di dati transitori sono perse (ad esempio, da un arresto).

Il fatto di separare i modelli che usiamo per le letture dai modelli che usiamo per le scritture non cambia l'idea principale di come inizializziamo - abbiamo solo due cose da inizializzare invece di una.

Quindi funziona nello stesso modo in cui lo farebbe se stessimo leggendo dati persistenti da un archivio di valori chiave o da un RDBMS. Abbiamo appena questo passaggio in più nel mezzo in cui, dopo aver letto la cronologia dal negozio persistente, dobbiamo eseguirne l'iterazione per arrivare allo stato "presente".