Hello
I am at the point where I have designed my simple Aggregate. I have some commands passed through a command gateway and I have an EventSourceRepository saving an XML serialisation of the events to a table called DomainEventEntry. I’ve got some other events subscribed which can save current state of the aggregate / domain objects to some object / relational tables. It’s looking good and the framework has given me a great leg up to get quickly to this point.
I’m going to have a look at the snapshoting functionality but I’d like to know whether there are any built-ins in the framework which can do event replay/ rewind / event audit for me. For example
-
knowing the identity of an object, replay from version 0 and provide a version of the aggregare with its state the way it was on a specified date, or up to a defined version. Additionally, provide an audit trail showing the changes at each revision.
-
for all objects, give me an aggregate which represents its state at a specified date
To satisfy the first bullet, everything is there in the DomainEventEntry table but it feels like an audit trail for a known object would be a common requirement across any usage of event sourcing. Is there such a thing in AXON ? Lookling at the implementation I have, the full aggregate is serialised as XML in the payload field of DomainEventEntry. Is there a way with Axon to make it just store the changes / deltas ?
For the second bullet, I can see that I could probably write something which generates state from the event log and stores that in a separate table. Maybe I can do this with snapshots ?
Thanks
Chris Faulkner
Hi Chris,
I guess I know what your asking, but not 100% on everything, so here goes.
Replaying:
If you’d like to replay the event store against an Event Handling class, you need to specify that your Event Handling class is part of a TrackingEventProcessor.
The TrackingEventProcessor keeps track of which event it applied to it’s Event Handling classes last by storing a Token.
If you’d remove that token, you’d effectively force a replay of all the events to the TrackingEventProcessor because it lost track of were it was and will thus apply events from the start.
To a specified date/index:
That’s currently not a thing incorporated in the EventProcessors, were we currently have a Subcribing and Tracking version. Additionally, that will not be a part of the EventProcessors, because the idea behind the processors is to start processing and work through the set of events. If you’d want to get specific results on certain dates or indexes, you’d have to implement a class which reads the event stream it self. That implementation can than chop up the results on desired points in time. So you’ve already answered this point yourself, in the description you give about bullet 2.
Audit Trail:
You should consider the events store as your audit trail. If you’d want the audit trail for a specific aggregate, you’d just have to grab all the events from your DomainEventEntry table with that specific Aggregate Identifier.
Lastly, I’m not sure what you mean with the complete aggregate states being stored as XML in the payload of a DomainEventEntry. The payload on the DomainEventEntry is the serialized event (xml/json/etc), so what you describe would mean that you’re storing the complete aggregate state in every event. If that’s what you’d want, that’s fine of course, but you could make your events more fine grained to only contain the deltas.
Hoping I’ve answered your questions thoroughly enough. If not, feel free to reach out again.
Cheers,
Steven van Beelen