domain-driven-designcqrsmemento

persistence of the snapshot/memento pattern


I understand that an aggregate root usually replays all events to put itself in the right state. This can become inefficient, hence people suggested the memento pattern to create a snapshot of the aggregate root. My understanding is that the domain model has nothing to do with persistence. I also think that the snapshot has nothing to do with read model. Could someone please be so kind and point out where the snapshots are usually persisted then? Thanks.


Solution

  • There are much way to do this, depending on the implementation you use to store your events.

    Most abstracted Event Store library (those who use an agnostic persistence storage such as MySQL, MongoDB, Redis, whatever), will usually do it on their own.

    If you implement your own mechanism, you may provide a Snapshot Service along with a Snapshot Strategy.

    For example, you may want to create a snapshot for every events, or every n revisions.

    Another solution is to have your EventStore implementation to publish events on some tubes that you can subscribe to and build your snapshot asynchronously.

    You may also run a scheduled task to build snapshot from time to time.

    If you use the EventStore persistence storage, which is a built-in event store, you probably won't need to snapshot, and you will most likely use projections to build computed states of your Event Stream.

    As a general recommendation, snapshotting has drawbacks. By using it, you are re-using a state persistence rather a sequence of events. Make sure you actually need it and there are no better solution to optimize your performance.

    Events are usually smalls messages objects and fast to load.