Mi sono imbattuto in un articolo di Lucas Majerowicz intitolato " Aggiungi funzionalità tipo git alla tua applicazione usando Event Sourcing ".
In esso, descrive l'utilizzo di Event Sourcing con eventi memorizzati come nodi in un database grafico (utilizza Neo4j). In tal modo, diventa banale ramificare l'archivio eventi da eventi arbitrari al fine di mantenere più stati di applicazione contemporaneamente (e in effetti quindi di unire eventi da un ramo a un altro).
Sono sorpreso di poter trovare relativamente poco altro scritto su questo approccio, in quanto sembra un'idea abbastanza utile. In effetti, la maggior parte della letteratura su Event Sourcing che riesco a trovare sembra condividere la mia ipotesi fino ad ora, che il negozio di eventi sia effettivamente un flusso lineare di eventi. (Naturalmente, si potrebbe ancora ottenere lo stesso effetto di ramificazione in un flusso lineare includendo in ogni evento l'identificativo del suo "evento predecessore", ma sarebbe molto più costoso ricostruire lo stato dell'applicazione utilizzando tale struttura).
Questo approccio (un'istanza di) descrive ciò che Martin Fowler sta descrivendo quando parla di Modelli paralleli ? Sembra certamente di alto livello, ma non riesco a vederlo arrivare vicino a descrivere un sistema che ramifica lo stato dell'applicazione in modo così libero.
Qualcosa su questo mi sta tormentando, che Event Sourcing dovrebbe essere un puro flusso di eventi. Inoltre, è proprio questo tipo di flessibilità che rende l'event sourcing così potente, ma è sorprendente che così pochi negozi di eventi utilizzino database di grafici in questo modo.
Mi sto prendendo in giro per niente?