Is there a mechanism within Axon (existing or in the planning) that would support snapshots not only for the Aggregates, but also for the read model ?
Kind regards,
Davod Stibbe
Hello Davod,
Snapshotting removes the need to reload and replay large numbers of events, which can be very good optimization if you choose to apply eventsourcing pattern within your command model.
Read model doesn’t have similar requirements. Read models are mostly projections (materialized views) of your command model (in this case you save the state of the object in the repository - no eventsourcing).
Now, if you would like to think of the the Snapshot definition as: “A single snapshot represents the entire aggregate state at a certain moment in time.” it would imply that read model is a current snapshot of an aggregate projection.
Best,
Ivan
I have the feeling that the read model is somewhat underrepresented in Axon. Even though it presents itself as a CQRS framework, the main focus seems to be on the C(ommand) model, somewhat neglecting the Q(uery) model.
Command models and Query/Read models are both projections of the events, but with different purpose. Therefore I would not find it strange to have both be sourced by the events and thus would like to snapshot these as well.
What I imagine/wish would be an architecture like the following, which is not Axon compatible… (hopefully it will line out properly):
CommandService ===[ Command ]===> Command model Aggregate ===[ Event ]===> Event Store
Read Model Aggregate <==[ Event ]========//
(replace complete model entry)
\====[ Id, Read Model ] ===> Read Database
/
Query Service ======[ Query ] =======> Query Handler ===============//
Kind regards,
David Stibbe
Do you have an example of what you need to do (domain wise, not technically)?
The Aggregate on command side is replayed every time it is needed.
This may take long for a lot of events. Snapshots should only speed that up like a cache.
If you delete every snapshot, nothing (but the performance) should be affected.
The Eventhandler on the query side processes the events only once and updates the query model persistent.
Do you need something like an always replaying query model?
I always thought of replays as technically driven, if e.g. the read model needs to be changed.
If you want a table containing specific changes of something on a time line,
you could introduce a new read model with a timestamp as key.
Snapshots are somewhat less reliable when it comes to schema changes (if your aggregate fields changes),
which is Hard enough with events (versioning...).