We are looking at axon to use for our next project, have few questions,
I understand that events are being persisted to event store by command handlers and to database by event handlers, how different is that from regular crud, we persist to database and read from database right i see no difference in your framework, I see one more problem for creating aggregates if we have 3 view aggregates then i got to keep updating views for any domain events, please guide us any best practices and design approaches. We basically want to develop driver user profile application. Thanks
Hi,
Command handlers are responsible for acepting commands (these are operations to change the state of you domain model). This state change is populated to the rest of the system by sending events. Technically, command handlers are manipulating aggregates and an aggregate is persisted by a repository. This repository can be EITHER relational OR event-sourced. In case of an event sourced repository, you store only the events - with the advantage, that you can replay all these events.
Now the view side is creating a (read-optimated) projection of relevant domain model aspects. They do so, by reacting on occured changes (events). Since the event source (the aggregate) and the event listners (one or many view sides) are decoupled from each other, so you don’t have to keep anything in-sync - this is accomplished by the Axon Framework.
Hope this helps,
kind regards,
Simon
Hi Ravinder,
Based on my understanding…You need to look at this in a different perspective. Definitely read on CQRS. AggregateRoot represents your domain, in this case – User.
Commands on User, updates write side model and fire events… An AggregateRoot current state will now reflect the fact that event has occurred.
If you have 3 views (could be 3 different datastores) – Updates to the different view model can be handled via EventHandler (you can have one or more).
Read side update works on the basis of eventual consistency.
Your Rest API would essentially fire the command, and return 200 (or 201 with a location URI to the read side resource)
Obviously, it may look as if we are adding a lot of unnecessary complexities, especially if you are trying to fit CQRS to an existing system. But it forces you to think in terms of your domain model.
Plus, if you do it right, it comes with some good features like, rebuild a read side by event replay etc.
You can do eventing in many different ways.
So, CQRS may or may not be the right solution to what you are trying to do.
-BG
Thanks Gopal for the info, What would be best use cases/ applications the CQRS best suit for? Baking apps/shopping cart/profile apps ?
Banking, Yes for sure. CQRS by nature gives you full auditing capabilities. For money transactions and such cases, eventual consistency makes sense too.
Just to add on. Also, take a look at the concept of Saga in CQRS. Sagas are long running transactions. They get initialized by an event that happened (say for example, DebtTransactionInitializedEvent),
they can continue to listen for more events (DebtTransactionCompletedEvent or RejectedEvent).
In short, You can implement complex scenarios in a Saga. Saga can keep track of the state of the transaction, and is persisted in database.
Hello Gopal,
I have a question regarding updates done on the read side.
How does the event processor manage large number of events. I have an application that involves several agents executing sale transactions. I get an average of 3000 transactions per minute. Each transaction is a command, that calls an event, and then has to update the agent balance field. Does the event processor hold all these events in a queue? In case of a system failure (for example a power outage), do I lose the events? MYSQL locks the database table when an update is being performed, thus can result in the other transactions timing out and not being updated. Do I then end up with some persisted events in the event store, but the necessary updates not performed?
I would appreciate any help in clarifying these worries.
Thanks in advance.
Hi everybody,
Diane, I’m going to focus on your question, which I think would have justified a different thread then what Ravinder originally requested.
I’d suggest using a ‘TrackingEventProcessor’ in the scenario you sketch.
The TrackingEventProcessor will periodically poll the event store for new events itself, rather than being called by another process.
Hence, this scenario does not use a queue.
In case of a restart of the system, the TrackingEventProcessors would just proceed at the last event it handled from the event store.
Axon will always first try to append an event in the store (as it’s your history which you can base all your views on), and only after that will it notify SubscribingEventProcessors or can TrackingEventProcessors retrieve the change (as it is polling the store it self).
Hope this helps you Diane, and please ask more questions if stuff is unclear 
Cheers,
Steven