C'è qualcosa di "sporco" nell'usare un negozio non lineare in Event Sourcing?

1

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?

    
posta eggyal 28.11.2017 - 00:00
fonte

1 risposta

1

Penso che il tuo istinto sia giusto.

Considera di ricostruire l'oggetto in tale albero. quando vieni in un ramo che fai? Che dire di snapshotting per ridurre lo spazio su disco?

Ho intenzione di uscire su un arto e dire che Eventsourcing è principalmente utilizzato per risolvere il problema delle transazioni atomiche nei sistemi distribuiti.

La ramificazione non ti aiuta qui, infatti è esattamente ciò che stai cercando di evitare.

Quindi sì, bella idea, ma forse ha bisogno di un nuovo nome per distinguerlo da "Event sourcing come lo conosciamo"?

    
risposta data 28.11.2017 - 16:22
fonte

Leggi altre domande sui tag