AxonFramework / AxonFramework

Framework for Evolutionary Message-Driven Microservices on the JVM
https://axoniq.io/
Apache License 2.0
3.32k stars 790 forks source link

Revise Snapshotting logic #3105

Open smcvb opened 2 months ago

smcvb commented 2 months ago

Long ago, the Snapshotting behavior in Axon Framework required users to define a dedicated "Snapshot Event" that would be stored in the Event Store after some form of trigger. As time progressed, a lot of this got automized in Axon Framework, leading to a scenario where users only had to define the SnapshotTriggerDefinition and be done with it.

The reason this worked out of the box was the use of the XStream Serializer. Through this, we could simply have the Aggregate's state as the snapshot at all times. However, when Java entered version 17, the existence of XStream, which is heavily based on reflection, became very unstable. Since this assumption is no longer viable, leading users towards options like Jackson, CBOR, or Kotlin, it would make sense to further open the "magic box" around snapshotting altogether.

Hence, we should take a lesson from how it used to work, but aim to simplify this approach. If users would again be able to easily define "what" the Snapshotter would define as the snapshot, we would return to a more flexible approach that allow users to separate the Aggregate from de-/serialization logic that would come from Jackson/CBOR/Kotlin-serialization.

The above, combined with the need to align with the new Unit of Work (as introduced in #2953), are the tasks at hand to revise the snapshotting logic within Axon Framework.

Lastly, it would be worthwhile to investigate how we could incorporate snapshotting validation within our Test Fixtures. Feel free to draft up the above into distinct pull requests to not overload the reviewer(s).