I just stumbled upon an article by Lucas Majerowicz titled "Add git-like functionality to your application using Event Sourcing".
In it, he describes using Event Sourcing with events stored as nodes in a graph database (he uses Neo4j). In so doing, it becomes trivial to branch the event store from arbitrary events in order to maintain multiple application states simultaneously (and indeed then to merge events from one branch onto another).
I'm surprised that I can find relatively little else written about this approach, as it seems like a pretty useful idea. Indeed, most of the literature on Event Sourcing that I can find appears to share my own assumption until now, that the event store is effectively a linear stream of events. (Of course, one could still achieve the same branching effect in such a linear stream by including in each event the identifier of its "predecessor event"—but it would be far more costly to reconstruct application state using such a structure).
Is this approach (an instance of) what Martin Fowler is describing when he talks about Parallel Models? It certainly appears to be at a high level, but then I can't see him getting anywhere close to describing a system that branches application state so freely.
Something about this is nagging at me, that Event Sourcing should be a pure stream of events. Then again, it's precisely this sort of flexibility that makes Event Sourcing so powerful—yet it's surprising that so few event stores use graph databases in this way.
Am I getting myself in a twist over nothing?
Best Answer
Actually branches are reasonably common.
Look at EventStore and the event type $linkTo this is a use case for it! Basically you can have many steams linking back to an event in different ways/orders.
I also discuss some patterns doing similar things in discussing stream/event versioning patterns in the versioning book https://leanpub.com/esversioning