Problem with Event Sourcing – reconstituting our objects

This is a question in response to Greg Young’s blog post CQRS and Event Sourcing:

It seems that a pretty big difference between Event Sourcing versus traditional DDD using an RDBMS is that one focuses on persisting the events, rather than snapshots of the objects.  A major advantage here is that you have a more enriching data experience – saving the events allows you to not only know the objects and states, but also all the events that took place to get you to your current place.  Imagining your domain’s current snapshot of data as a two-dimensional object, event sourcing gives you a third dimension of perspective.  It doesn’t give you a static, current snapshot, but can provide the actions and history – giving you a much richer experience of being able to use the data.  However, I have an issue.  Sometimes, the snapshot is exactly what I want.  I may need to know exactly the data from one object and use that in another process.  In a cold state where the given object is not in memory, I want to be able to pull the object and perform some action on that object, which is an interaction with the object and its current state.  So, let’s say I have an object foo that I need to perform some action (this event relies on the object’s current state).  How do I reconstitute that object into its current state efficiently?  If this object has a long history, I may have to reconstitute the object by iterating over all of its events and rebuild the object from scratch.  Or even worse, if the object’s history intermingles with other objects and their events, I have to pull multiple objects’ histories and perform all the same actions against them to get the object caught up to its current state.  In an event-only storage system, this third-dimesional domain perspective now works against me.  In a dual-storage system, at least, you still have the latest copy (albeit your argument is that these current-state-snapshots are not as reliable as the events).

Is there a trick to pulling the most current snapshot of an object into memory?  Or do you discriminate between processes and objects that work better with Event Sourcing and those that work better with object-snapshot storage?  Furthermore, what happens when reconstituting an object based on past events is not a deterministic action (say, the action/event changed or a bug was found in an event that was fixed).  In other words, code is fluid and changes often.  How reliable is a snapshot of an event long ago in an object’s history when the function or process may have changed, however slightly.  There’s no longer a deterministic process that will always generate the same values for our object that will be historically accurate.  Does a change in an event’s actions become an event itself?  I.e., are we now forcing our developers to write “Event_Changed” events?  I started to write a concrete example, but it was complete crap, so if I’m unclear just let me know.

It seemed easier to post a blog than drop this entire thing in the comments section  😛


Tags: , , , ,

One Response to “Problem with Event Sourcing – reconstituting our objects”

  1. Chad Says:

    You can still have a snapshot of the object when you are loading it from the event store. Basically, you would have a mechanism for snapshotting objects every x number of events. Then, when you are loading the object from the event store, you only have to load the snapshot and replay any events that have happened after that. The difference between this snapshot and the domain objects of traditional DDD is that this snapshot is not durable. You can easily throw it away and rebuild it from the events again. And the only reason you would want to implement this is for performance reasons – like you said – if there is a very large number of events for a single aggregate root.

    Mark Nijhof has a good series of introductory posts if you want to learn more:

    He also has a really good code sample that makes a lot of these ideas more concrete along with a video where he explains all of it:

    To answer your question about the events changing — the events don’t change. One of the benefits of event sourcing is that the events become your audit log. There are other ways to deal with versioning and bugs and such. Again, Mark has a good post about it (see my comment on that post for some reservations I had with that approach):

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: