I've been researching Event Sourcing, and it seems there are two philosophies hidden within what I've read. The core difference is whether actors in the system are proactive, making changes first and publishing events based on what they have done, or reactive, consuming events and updating data based on those events.
However, the former isn't really Event Sourcing, right? The events aren't the source of change, but just a record of change. That's just an event-based log that can be used to rebuild the data later. When you rebuild the log, you're using different code than when you executed in the first place; in the original run, you send an event that you read the second time around. On top of all of that, you have to introduce commands to actually trigger those changes, which need to be sent directly to the consumer, causing a tighter binding.
Meanwhile, the "reactive" style reverses all of those concerns. Since every change is a reaction to an event, there's basically no difference between listening to the "live" system as it churns on and listening to a replay sometime later. There's no need for explicit "commands", because services aren't told what to do. Rather, they're in charge of maintaining consistency in the face of the events that occur elsewhere, and of notifying others of their own events. The flip side of this is an inversion of control: instead of knowing about other services/aggregates so you can tell them what to do, you just broadcast your event to the system and let them respond according to their rules. The only comparative downside I see is that you have to explicitly ignore new messages when replaying old messages, but that can be done with configuration/flags.
And yet, many guides and products seem to endorse a proactive style. For example, Event Store expects events to be divided into streams based on their target - meaning there is only one target per event, as if you're either sending it to a single, designated target (which makes it a glorified command) OR because the "target" is really just the source making a record of the action it took.
There must be a gap in my understanding, but after a week or so of reading I haven't come across a well-supported explanation for this. I suppose two questions come out of this:
- Which of these two approaches is truly Event Sourcing?
- Are there benefits that the proactive approach has over the reactive approach that I haven't mentioned here?