EventSourceHandler's called for previous Events - before calling CommandHandler

Architectural Concepts
1

Hi All,
Im new to Axon Framework, so forgive me for any nonsense i might be writing!

At the moment im beginning to understand how does the framework work in order to apply this to a project.

Lets say we have an UserAggregate class (@Aggregate).
in this class we have:

  • RegisterUserCommand (annotated method @CommandHandler), that triggers a RegisterUserEvent

  • UpdateUserCommand (annotated method @CommandHandler) that triggers a UpdateUserEvent

We also have 2 EventSourceHandlers (1 for each event)

Lets say that i follow the bellow sequence:
1 - RegisterUser -
2 - UpdateUser (1st update)
3 - UpdateUser ( 2nd update - changed some other property)

When i was debugging my 3rd operation (2nd update) i noticed that the following happened in this order (after sending the Command to the commandGateway of course)

1 - The EventSourceHandler for the RegisterUserEvent was called
2 - The EventSourceHandler for the 1st UpdateUserEvent was called (with the correspondent values of the 1st update)
3 - The CommandHandler for the UpdateUserCommand was called
4 - The EventSourceHandler for the 2nd UpdateUserEvent was called

When i fire the 2nd UserUpdate i was expecting that 3 and 4 alright, so my question is:
why is the EventSourceHandler’s of the previous events for that AggregateId being triggered? is this to rebuild the state of the Aggregate?

2

Hello Daniel,

To answer your question, is this to rebuild the state of the Aggregate?
Yes, this is expected behavior. It is known as the Event Sourcing pattern.

Previous to actually handling the command in CommandHandler, Axon Framework will

  1. read all the events (with aggregate ID) from the event store (Axon Server or some other DB)
  2. execute all EventSourceHandler’s that are matching the event types to build the current state of the aggregate.
  3. execute the CommandHandler. At this point, you have a state of the aggregate and new command so you can make further decisions by publishing new events. CommandHandler can validate the correctness of the intent/command based on the current state of the aggregate.
  4. New event is published and EventSourceHandler will be executed for that particular event to prove that the state of the aggregate can be constructed.

In traditional systems, you would store the state of your entity by overwriting the previous state.
Event sourced systems are only appending events into the storage, providing you with a different way of storing your data. This way will give you 100% audit, and allow you to keep all the history. (information is valuable).

Snapshotting could be used to optimize the event sourcing pattern: Event Snapshots - Axon Reference Guide.

Best,
Ivan

1 Like
3

Hi Daniel,

what is Ivan says already answers your question, but I want to make a small addition.

Consider the @Aggregate marked class as the instance responsible for receiving commands and sending events only. If you apply the CQRS/ES pattern, the aggregate is only the command model - responsible for validation of commands (the C-part of your CQRS system). It is not intended to hold all your the state - this is usually the task of the Query model(s) (the Q-part of your system).

So consider to minimize the data stored in the aggregate to only that which are required for command validation. In more details, validate if you really require both @EventSourcingHandlers.

Cheers,

Simon

1 Like
4

This is a very good point. Thanks Simon!