Aggregate state in Saga

I’d like to make sure that getting the aggregate state inside saga’s @SagaEventHandler is ok (not against any patterns/principles), since I need to be aware of the actual aggregate internal state to decide what to do next in saga

Having in my Saga:


Of course, the method on(…) is annotated by @SagaEventHandler

@SagaEventHandler public void on(ApplicationStateChangedEvent event){ .... }

Hi Tomáš,

this is actually against principles. Your aggregate should only maintain state that it requires itself to decide what it should do on incoming commands. It may accidentally be that this is also state that the Saga required. In that case, I would recommend implementing that state inside the Saga, too. Reading from your aggregate gives you coupling between the Saga and the aggregate (tying them to the same service) and forces the Aggregate to be able to expose this state.

Alternatively, you could consider extracting certain logic to services/entities/value objects so that both your aggregate as well as the Saga can use it.

I hope this helps.