I'll first explain the context of my problem. The backend of my current project is using DDD, CQRS and Event Sourcing as a stack (the read DB being a MongoDB, my write DB being an event store).
At some point I had to chain multiple commands in a "transactional" manner, did some research and had to choose between listening to events or implement them using a saga, I decided to go with listeners.
So the flow is as following: Command A is launched, a handler catches it, get's the aggregate corresponding the command, aggregate does his business logic which generates Event A, then aggregate is persisted to the event store (the generated event is stored in a list of uncommitted events in the aggregate, and the repository only persists those events).
So when event A is persisted it's added to the event stream and a handler listens to all the events coming there and a message broker recreates the event and publishes it for potential listeners.
A listener catches Event A, and creates a Command B according to information in Event A, which then sends an Event B, and so on.
My read side is synchronized in the same manner, there are listeners which listens to the events sent by the broker, and the read models are populated / adapted.
So here is the actual problem, this all works perfectly, but there is 1 catch here. Let say I want to recreate my read DB, i drop it, relaunch it, all the events are re-applied in the right sequence, my read model listeners catches the events and apply it to my model, fine, but the problem is that my write side listeners also listen to those incoming events, which is problematic because this causes a command to be launched while.
A solution would be to implement sagas, which will remove the write side listeners, but I really like this approach so I'd like sagas to be a last resort option, but I can't seem to wrap my head around how to actually split those 2 types of listeners, so any ideas ?
Sorry for the long read, but I had to explain it as a whole picture to get good suggestions.