So, what am I missing?
Indovina.
La prima cosa che potresti mancare è che hai solo bisogno di ricaricare gli eventi per lo stato che stai ricostruendo. Se è possibile modellare in modo pulito i limiti delle transazioni, ogni oggetto può scrivere eventi contrassegnati con il proprio ID e quindi rileggere solo in tali eventi. Utilizzando un database relazionale per l'archiviazione degli eventi, ci sarebbe una colonna ID indicizzata per accelerare tale query. Usando EventStore, ogni oggetto avrà il proprio stream.
Ci vuole un po 'di attenzione nel modello per farlo in modo pulito, in quanto si vuole essere sicuri di modificare un singolo oggetto in ogni transazione, e quindi è necessario fare attenzione a isolare correttamente ogni invariante che si stanno cercando di far rispettare.
Nei casi in cui non è abbastanza veloce, hai ancora la possibilità di creare istantanee del tuo stato (memoizzazione), e persistente in "archiviazione tradizionale". Ogni istantanea viene taggata con il numero di sequenza dell'ultimo evento utilizzato per creare l'istantanea; al momento del caricamento, il repository cattura prima quella istantanea, quindi applica gli eventi più recenti. (Ciò implica un modo ragionevole per catturare le istantanee più recenti - o gli eventi sono anche contrassegnati con il numero di sequenza, o hai un modo efficace per leggere il flusso di eventi all'indietro fino a raggiungere il punto di partenza.)
C'è ancora un vantaggio rispetto al solito approccio qui, dato che le tue istantanee possono essere costruite parallelamente alle tue scritture, piuttosto che essere unite a loro: basta mettere un listener di eventi in qualche altro thread / processo, e lasciarlo allegramente insieme scrivere al negozio di istantanee su qualsiasi programma sembra ragionevole. Dopotutto, l'istantanea non ha bisogno di essere particolarmente tempestiva, solo abbastanza spesso che il lavoro di riapplicazione degli eventi più recenti non fa esplodere il tuo SLA.
(Snapshotting complica la migrazione, eventuali modifiche alla serializzazione del modello invalideranno la cache dell'istantanea. Naturalmente, puoi ricostruire le istantanee utilizzando la nuova serializzazione come parte della migrazione e poi "recuperare" quando le modifiche vanno vivere.)
Is restoring state from the event stream even commonly done?
Sì, lo è. Ciò che normalmente viene mostrato negli esempi CQRS è che il livello Application, dopo aver verificato che il comando inviato sia ben formato, il livello applicazione caricherà l'oggetto dominio da un repository, dove il carico è un costruttore predefinito seguito da una riproduzione del flusso di eventi (o in modo equivalente, una chiamata a una fabbrica con un elenco di eventi).
Altri due pensieri contraddittori.
- Potrebbe esserci una cache dietro l'interfaccia del repository
- L'invalidazione della cache è uno dei due problemi più difficili.