Event sourcing of sagas

Hi Allard,

Is there any plans for adding a support of event sourcing for managing
a saga state?

Thanks in advance and keep up the good work!

Regards,
Eugene

Hi Eugene,

currently, I have no plans to do so. So far, I haven’t come across a situation where it seems to be very beneficial to apply event sourcing to Sagas. In fact, the Event is the trigger for Saga activity. That means you’d need to distinguish between a replayed event and a “new” event.

What is it that event sourcing in Sagas provides that you currently miss?

Cheers,

Allard

Hi Allard,
Thanks for your response!
Yes, I understand that there is a difference in event handling of the
Event that triggers a Saga activity and Event as a source of a Saga
state change.
But from what I can see in Axon framework you are currently have at
least different event handler annotations(@EvenHandler and
@SagaEventHandler),
so it seems that there should not be any problems to distinguish the
event handlers in the Saga.
Current implementation of Sagas should work fine in most scenarios.
In case of state-full Sagas as a way to implement processes and/or
communications between bounded contexts -
I think that having an ability to know how we get to some state is a
good thing.
I'll try to come up with a relatively small example and please correct
me if I'm missing something.
I've created a Gist for it - https://gist.github.com/1385842

In case if let's say one month later after the system is in production
we will decide to take a look on
how many users were asking us to re-send them a confirmation e-mail
before they've completed the registration process -
it seems that we will not have that knowledge in our system storing
just a final state.
I know that this may not be the case for a real-life scenario, but in
a system that I'm working on
we will have such processes and I'll be glad to have an ability to
track the state changes in them.
Any feedback will be appreciated!
Thanks in advance!!!
Regards,Eugene

Hi Eugene,

in your example, if you were to look for all users that have been resent their registration email, you’d go to the event store. You don’t need event sourced sagas for that. In fact, a Saga itself should never change state (other than in itself) of the application. It should send out commands to do so. This will give you the ability to trace all activity.

My scepticism for event sourcing sagas is twofold. First of all, you’d be logging events that are already logged as part of the Aggregate’s event log. So it’s a duplicate.
Secondly, events are the Saga’s input, not their output. If you were to succesfully event source Saga’s, you’d need to store very different information. That would be things like “apply(NewCommandToRequestResendingConfirmationEmailSent)”.

If you want to know which events arrived at the Saga in which order, and what their corresponding activity (i.e. sent command) is, you could simply log the ID’s of all incoming events in the Saga and use correlation ID’s to correlate each command to its originating event. In Axon 2, this type of metadata will be much more explicit than it is right now.

Don’t get me wrong, it’s not that I don’t want to build event sourcing for Saga’s. It’s just that I don’t see the area of benefit yet. And without seeing that, it’s a bit hard to implement something that fits best at providing that benefit.

Cheers,

Allard