RE: [axonframework] Re: differences between @eventhandler and @eventsourcinghandler

Imported from Google Groups
1

Hi Joseph,

Thanks a lot for your detailed explanations. However, I have further questions for you:

The EventSourcingHandler is on the command side’s Aggregate to dictate how the Aggregate will change, given that event. EventHandlers are normally on query applications/side to dictate what to do once an event has occurred. Strictly speaking, EventHandlers are optional (you are able to have the updated Aggregate (think of it a state machine), by going through the events in the event store, and updating it along the way through the EventSourcingHandlers.

  1. It seems to me, if I understand correctly, actually you would like to use @eventsourcinghandler as a write/state changing side (in CQRS) or command side events listener that responsible for state changing events, @eventhandlers as the read side (in CQRS) or query side events listener that responsible for query based events? However it leads to my next question:

Once an EventSourcingHandler has finished executing, the event is published to the EventBus, which is then caught by the EventHandlers.

  1. In practice, if I use both @eventsourcinghandlers and @eventhandlers in one component to accept the same type of events, does it mean, I can receive the same type of events twice?
  2. When I checked your online reference manual, I found that, currently you only tracking command side events, do you have mechanisms to track query side events?
  3. Your query handling is for the domain data queries, not for the tracked events, right? How about if I would like to query inside your event store for the tracked events? It has a lot of practical useabilities.
  4. How can Axon do the events replay?

Regarding the Axon system usage:

  1. The functionalities Axon is providing for me seems that Axon provides a message based wrapper for all the data transferred inside e.g., a spring boot application. Axon wraps all the query or command request/response data inside the different msgs and track all the msgs’ happening information with event sourcing. My question is: does it mean that Axon actually provide a separate layer paralleled with the specific business domain applications, you have your own event store database, your separate event sending/receiving bus, and business applications have to feed/fetch information into/from Axon if they would like to benefit from Axon framework?

Thanks again. (this email only for technical discussions for better understanding Axon system, no positive or negative arguments)

Best regards.

Qian Liu

2

Hi Qian,

  1. In practice, if I use both @eventsourcinghandlers and @eventhandlers in one component to accept the same type of events, does it mean, I can receive the same type of events twice?

    Yes, before the event is sent to the Event Bus it is handled by the EventSourcingHandler, and then by ANY EventHandler that handles that event, which is why if you’re in a single module scenario, I would prefer eliminating EventHandler.

  2. When I checked your online reference manual, I found that, currently you only tracking command side events, do you have mechanisms to track query side events?

    It is not really SourceHandler being command and Handler being query. They are both repercussions of a Command. HOWEVER, were you to split your project into a Command Service and a Query Service, the @EventSourceHandler would be in the Command Service, since that is where your aggregate should be, and is updated in the @EventSourceHandler, while the @EventHandlers would be in the Query Service, in order to store data in a read model (Eg: Data Warehouse) in preparation and for the sole purpose of that Query Service’s incoming queries. This is so that incoming queries query that service’s model, whatever it may be, regardless of the event store (which is how Axon is ideal for independent scalability).

  3. Your query handling is for the domain data queries, not for the tracked events, right? How about if I would like to query inside your event store for the tracked events? It has a lot of practical useabilities.

    Correct, the Query Handling does not need to know about the event store, Aggregates, and the lot. I have never implemented an endpoint to query event histories, but I just ran across this this morning, maybe it may help: https://groups.google.com/forum/#!topic/axonframework/ec4TFliF77M.

  4. How can Axon do the events replay?

    By default, Axon initializes a TrackingEventProcessor. On startup this TrackingEventProcessor queries the Event Store for any non-processed (by the module it resides in) events and replays them. So at this point, if you simply restart a Query module, it will replay ALL events made. However, you may also declare your own TrackingEventProcessor with a custom TrackingToken to avoid this should you need to. I have an implementation of this at https://github.com/grechjoseph/axon-distributed/blob/7-ignore-event-made-prior-to-startup/axon-query-one/src/main/java/com/jg/axonqueryone/config/AxonConfiguration.java, with the help of https://www.michielrook.nl/2017/09/using-tracking-processors-replay-events-axon-framework-3/.

    There are two types of EventProcessors, Tracking Event Processor queries the event store from the Query module’s Thread, ie: why on application startup the above occurs. The other is a Subscribed Event Processor, where the Query module subscribed to the Command Module and waits for the Command module (the @EventSourcingHandler) to publish the Events to the Event Bus. More on this in the same link https://www.michielrook.nl/2017/09/using-tracking-processors-replay-events-axon-framework-3/.

    Regarding the Axon system usage:

    1. The functionalities Axon is providing for me seems that Axon provides a message based wrapper for all the data transferred inside e.g., a spring boot application. Axon wraps all the query or command request/response data inside the different msgs and track all the msgs’ happening information with event sourcing. My question is: does it mean that Axon actually provide a separate layer paralleled with the specific business domain applications, you have your own event store database, your separate event sending/receiving bus, and business applications have to feed/fetch information into/from Axon if they would like to benefit from Axon framework?

      Correct, emphasis on Axon and not the Axon Event Store though, and you have a single source of truth for both the Entities’ state and audits in the Event Store. Your modules can have their own model depending on their scope (for example, ignoring values that are irrelevant to the module, adding additional values that are relevant to the module but missing in the event, have a business application using a relational database as the read model, have a BI module using a Data Warehouse, but for any of these, the EventStore is the single source of truth, and any module coming into the party later, can have all previous event replayed on startup to sync up with the rest)

3

I think I failed to answer your second question properly in my reply… If by tracking queries you are referring to logging QueryCommands, then I’d suppose so, but I never tried it :wink: