My naive interpretation of the view part of the application was to create an event listener and to construct some view projection based on events.
This can be in-memory (Hashmap?) or persistent - from H2 DB to real JPA data store with a RDBMS behind.
If I want to query this view side, I would put a Repository (e.g. a JPARepository) and expose the read methods.
Could you explain what are the Query Handlers used for and how they match into this picture?
Axon aims to decouple components by providing abstractions for the communication between them. In essence, this means that messages like commands and events are sent over a bus, and the sender doesn’t know (nor should care) where the recipient of that message is located.
This is exactly the same for queries. It has been a part of the architecture that has been skipped for a long time, in the belief that it was about command and events, primarily, and queries would be “business as usual”.
However, that vision has changed in the last couple of years. Axon is not “just” a CQRS framework, but rather an “Evolutionary Event-Driven Microservices” framework. Queries can follow quite complex patters, way beyond the HTTP-GET-style “hey you, give me this”. For example the scatter-gather query (everyone, tell me what you know about …) or the subscription query (keep me up to date on …).
That’s the goal of the Query Bus.
Hope it makes sense.
Cheers,
Allard
PS. The API doesn’t quite work great yet, so we’re expecting to make some slight (backwards compatible) changes and additions to it.
that makes absolutely sense. Knowing that every change is reasoned by an event, interesting caching strategies on the query side may apply.
I wish more references to architectural discussiona or whitepapers on this or other Axon/CQRS features.
Will look under the Christmas tree, may be I’ll find some
That’s exactly what we are planning to use it for as well!
We hope to be able to include the subscription queries in 3.2. There’s a few nitty gritty API related things to sort out before we can…
In one of my previous project, we have built something like this specific to the project. It was a blast to work with. The server would just use JsonDiff to send updates to the client, which would JsonPatch to apply these to its model. Using Angular (but most frameworks would allow you to do this), this would automatically trigger the view to be updated as well. Result: real-time views on the client. Updating view models (also structural changes between updates) were very simple to make, because the server essentially dictated how the view on the client was built…
