Event Sourcing with Axon

Imported from Google Groups
1

Good evening

I am a newbie with Axon. I have a question about Event Sourcing with Axon. I am looking for an opinion and hear your experience with event sourcing

  1. A command is triggered using a CommandGateway
  2. A command handler capture the command and apply an event.
  3. An eventsourcing handler passes the values from the event to the aggregator
  4. An eventhandler will execute to save the data into the read model

That is my little knowledge in how Axon works. After that everything is cloudy.

My read model is a table in Postgres. That I am saving it when and event handler happens. Notice that I am not combining the eventsourcinghandler annotation with the eventhandler. Is that the correct approach? I have been reading about event sourcing that you need to read all the events from the event source to obtain the current state, however, I have not found how this work with Axon.

Also, I have read that you can basically create a process where load all the events in memory so it can be used for the application during the day, but if that is the case I guess my point 4 should not happen.

Could someone explain a little bit more about how this happen or can be done in Axon? Maybe my question does not make any sense, but if do not could you also please tell me how can I do a read model with Axon.

Richard

2

Note that there is a more generic DDD/CQRS google groups as well, you should subscribe there to get more into the cqrs way of thinking.

The current state of the AR is reconstructed each time you send a command to the AR. The eventstream is read and all events are applied in sequence (basically your @EventSourcingHandler annotated methods are called) to the AR. This is fully taken care of by Axon. The AR is just there to preserve consistency and validity of your model. It should contain just the data it needs to safeguard this consistency.

If you find that your read model strongly resembles your AR then well ok maybe cqrs is a bit overkill. Also, you could just decide to not have a read model at all then. The read side is optional, and if performance requirements and such allow it you could just let Axon reconstruct your data each time. For small and very simple models this is a valid approach IMO.

Jorg

3

Richard,

there is how the flow works:

  • you dispatch a command through a CommandGateway (or CommandBus directly)
  • the command bus routes the command to a command handler, which is usually defined on an Aggregate (either Root entity or any of its child entities)
  • Axon loads the correct aggregate instance (based on @TargetAggregateIdentifier annotation on command’s field)
  • loading the aggregate -if it is event sourced- causes Axon to load the aggregate’s past event and replay them on an empty aggregate instance.
  • The command handler is invoked with the command object
  • the handler (probably) applies events
  • Axon invokes the @EventSourcingHandlers inside the aggregate
  • Axon stages the event for publication on the Event Bus
  • When the command handler completes succesfully, the event is published to all @EventHandler components in the application, via the Event Bus.

Hope that helps.

Cheers,

Allard

4

Thanks Jorg and Allard

Could you help me understand a couple things? When you mean “if it is event sourcing” that means that you can set Axon to not to be event sourcing, right? Is the Event Sourcing a default behavior?

If Axon is playing all the events for producing an aggregate how that aggregate can be used for a read request for example (Of course if what I am saying makes sense).

In other readings people say that they used Redis, for example, to have the reading model available, in this case, how can handle this with Axon? Maybe I confused with two subjects, but if you could kindly point to the right direction I would appreciate it.

Richard

5

Hi Richard,

Event Sourcing is a choice. You can choose to store your aggregate state and use that to reconstruct it. In Axon, Event Sourcing is the default when you provide an Event Store. You can store an Aggregate based on its state by configuring a different Repository, such as the JpaRepository.

Note that Aggregates work on the C-side of CQRS. You don’t use them for querying. On the query side, you should exclusively use query models (a.k.a. projections). How you store these projections, is completely up to you. In many cases it’s a relational model in a database, but Redis could be a better fit in certain scenarios.

Cheers,

Allard

6

Thanks Allard, I am going to research a bit more Redis

Richard