Event Sourcing and Event / Aggregate Versions

Question

I've just been trying to learn a bit more about CQRS and Event Sourcing.

Looking through examples, and blogs, I see a lot of example event structures that are something like this

public class Event
{
    public Guid AggregateId {get; set;}
    public string Data {get; set;} //some serialized data
    public int Version {get; set;}
}

and then the Aggregate

public class Aggregate
{
    public Guid AggregateId {get; set;}
    public string Name {get; set;}
    public int Version {get; set;}
}

What I don't understand is what this version integer is for, and maybe my lack of the big picture understanding is why I can't seem to find an answer.

Is it simply a counter of what event we're on in ascending order? Is it actually a version of event, for like if you change the schema or something?

And same with Aggregates, when I look at different aggregates and I see one at version 1, and one at version 2, what exactly is that suppose to mean to me?

Yves Reynhout Yves Reynhout · Accepted Answer · 2014-11-01T23:32:34

The version on the event is actually metadata embedded in the event payload for easier access for any consuming code. It is the position of the event within a particular stream, typically partitioned along the axis of an aggregate.

Now, some framework/libs need to carry over the version number an aggregate is at (i.e. the last taken position when the aggregate was read) from reading it to writing it (appending new events), which is why you'll find it on the body of an aggregate base class. So in essence it's there for optimistic concurrency reasons.

Contract or schema versioning often translates into the name of the type or some attribute sprinkled on the type (e.g. xml schema namespace), not in the payload itself (well, not commonly).

Obviously anything represented as meta data can be embedded and vice versa.

Event Sourcing and Event / Aggregate Versions

1 Answers