I am new to the axon framework. I studied the theory of the CQRS pattern. I understood that CUD is kept separate from reading operations and they both constitute 2 different services. My assumption was I will have 2 Databases with the same tables and relation(CUD will have non-indexed table, read will have completely indexed tables) which have to be synchronized. Now I started looking at the implementation of the CQRS command part has become a nightmare to understand completely. I ran a few examples and saw that DB tables created are completely different. If anyone has gone through the same situation can you please explain in simple words how is it different in axon framework with respect my understanding
1 Answers
3
votes
CQRS dictates that you will have two distinct models, the Command Model and the Query Model, within a single "application sphere"/context so you will.
How both models are represented from a storage perspective is entirely dependent on the implementation details, whereas you are placing the assumption you will be using regular RDBMS with/without indexed tables.
The matter of synchronization is again an entirely different one to tackle, where you have several options again. As it stands, I have a pretty good understanding of Axon, so let me break down what's been chosen from it's perspective:
Command Model storage: You can either choose to store the Command Model as-is or through Event Sourcing. The first solution, which Axon prefers to call "the state-stored approach" thus means you will have a relatively plain entity format of the Command Model. The Event Sourcing solution on the other hand enforces the use of an Event Store. Upon retrieval from the Command Model Repository, an empty instance of the Command Model will be created and all the events which that instance has published will be replayed against the empty version. This effectively recreates the command model every time you retrieve it.
Query Model storage: As you might have noticed, Axon does not make a choice here at all. It is entirely up to the user what storage mechanism it uses.
Model Synchronization: As mentioned earlier, there are several option imaginable. The option chosen by Axon is that of an Event-Driven Architecture. Thus, the Command Model receives a command (the request of intent to perform some operation) and decides upon the request. As outcome, an event will be published, effectively "factualizing" the decision. This event is then propagated, asynchronously, to each component interested in it. These "components" are for example the classes updating the Query Models you have derived in your application.
Hope this does justice to the questions you might have Darshu!
