Event Sourcing and rebuilding logic

Question

I am new to event sourcing and i am bit confused about Rebuilding the Objects from the event Stream.

I believe we need to run load all the events happened from the chronological order to rebuild the object state. So for Example

If i have a Object Called customer.

Public class Customer
{
   public void Correctname(string firstName,string lastName)
    {
        CustomerNameChanged(new nameChangedEvent(firstName,lastName);
    }
}

If the Customer changed the Name twice we will be storing the event twice in the eventlog and when i rebuild the events to object i will get the event twice . Is it needed to take the previous event or archieve the events so that we dont rerun the last event again

The danger of omitting events from a stream during replay, is that you're making ASSUMPTIONS that only hold true with the current version of your object model. Things tend to change ... — Yves Reynhout, Jun 25 '12 at 07:21

score 3 · Answer 1 · answered May 28 '12 at 09:31

3

You would re-apply both events to the Customer object. Because you apply them in chronological order the Customer object will be in the correct current state. If you are concerned about the number of events being applied that no longer represent the current state, you should look at Snapshots

answered May 28 '12 at 09:31

David Masters

8,069
2
44
75

,actually when rebuild the Object IMHO the second event is not useful in my opinion(or am i missing something) , so why cant we get the unique events from the top and reapply it. The remaining events is needed only if we need to bring the object to current state on particular time . – satish May 28 '12 at 09:52
2

You could say "only get the most recent 'CustomerNameChanged' event". That might work for a name change which in terms of domain logic is meaningless, but this approach won't work for an event such as 'AccountBalanceIncreased'. Here the previous events are required in order for the entity to return back to it's current state; this will be the case for most of the time. Additionally, if you were to try and filter out the most recent events, you will have to add query logic for each entity's events which would be a major pain. You are much better off doing snapshots if performance concerns you. – David Masters May 28 '12 at 10:00
Thanks @david . That make complete Sense. But for the Account balance Increase , how will the snapshot look, will it calculate the amount upto the time and keep as a snapshot – satish May 28 '12 at 10:07
2

With account balance, the object would have a 'Balance' property which would be incremented each time the AccountBalanceIncreased event is applied. After X amounts of events you could create a Snapshot object which is just a data object that represents the entire objects current state, and copy the Balance property from the entity to the snapshot object and save it in the DB. The idea being that when you come to fetching an object, you first look for the latest snapshot then apply any events that have occurred after that snapshot. Useful if your objects have a long lifetime with many events. – David Masters May 28 '12 at 10:18

score 2 · Answer 2 · answered May 28 '12 at 09:33

When rebuilding an object you process the entire event stream for that object. Performance wise this is usually not an isssue, even for large numbers of events. You can mitigate this by using Rolling Snapshots.

With snapshots you store the state of your object at a particular point of the event stream. Rebuilding is simply loading that snapshot + events that happened after the snapshot was taken.

Event Sourcing and rebuilding logic

2 Answers2