How to replay commands in an event-sourced environment

I have run into this kind of issue in the past when event sourcing was new and shiney and people thought it might work.

The problem is you want to be able replay commands, that's the level that works on common sense. But commands have effects outside of the event source stream. Sometimes you want these effects and sometimes your dont.

eg I change the Customer service logic to fix a bug. say the customer count wasn't updating. I want to replay all the add customer commands so that the bug fixed logic is applied to the end result. BUT each added customer gets an email, I don't want them to get them all again!

If I try to fix this by splitting commands and events I either find that the event is too low level to pick up on the changed logic ie Event CustomerName new = "bob" old = "bobb" or too high level and is essentially a command, picking up on the email sending as well as the total updating

If I try to fix it by having some "should run" flag on effects, well sometimes I DO want the effect! there's no easy dividing line to draw. Maybe I want to resend all the emails without updating the db?!

Event Sourcing works well for document changes. Add this, remove that, change this other etc I want the end state but also the way it got there and be able to undo, replay, edit etc. All effects are changes to the document, there's no side effects

It doesn't work well for commands in CQRS or Event Driven systems and I don't know why these ideas are constantly wrapped up with each other.

Customer Service may do some validation, further logic and then update its own (non-persistent) internal database.

When people are talking about CQRS ("command query responsibility segregation") combined with ES ("event sourcing"), the usual context is that the representation of history used in processing commands is events (which might be a non-persistent internal event store, but more commonly a persistent external event store).

In other words, all of the information that the service wants to remember "later" is done by writing that information into events, which are themselves written into a collection.

So rehydration / reconstitution is "just" a matter of reloading the events. This is usually done with an ordered sequence of events and a "reducer" / "fold" / "builder" that copies the information from the events into some data structure that we call "the state".

In some rare cases the state will just be an ordered sequence of events, but it's a lot more common to cache the useful information into some data structure that is sensible for the kinds of queries that are going to be handled (remember: CQRS is two object where there once was one).

And yes, this rehydration of events from a history is side effect free; separation of concerns, and all that.

Sharing information this service has written down for its own use with other systems... well, assuming that allowing other services to couple to your data models is the right trade off, is typically done by having the other service pull from the store, keeping track of their own pointer into the event history. So if you want to "resend" a bunch of events to "Other Service", you do that by resetting the pointer location on the other service subscription.

But you want to be careful about that, for the same kinds of reasons that you want to be careful about coupling other services to your relational database schema.

Another way of thinking about what's going on: in some ways, our domain code is just a function, that accepts a command message and an event history as arguments, and returns a directed acyclic graph of actions to take (where one of those actions might be "update the event store").

In that model, rehydrating state is easy, because all of the "do actions" code is somewhere else; the rehydrating logic is "just" manipulation of information in memory.

The confusion here isn't your fault; The Literature Sucks [tm]. CQRS / ES falls somewhere in the intersection of Bertrand Meyers distinction between "commands" and "queries", Gregor Hohpe's "command message" and "event message" integration patterns, Martin Fowler's "Domain Event" and "Event Sourcing", event driven architectures.... Lots of places where the same sequence of letters is a label for some concept, but not a single concept that is shared by all.

Caveat lector: the modern reader has to be really vigilant about both (a) which domain the author is in and (b) whether the author themselves is familiar with the fact that the labels don't all mean the same thing.