Event Sourcing: Versioning aggregates

182 views
Skip to first unread message

Vladik Khononov

unread,
Apr 9, 2014, 7:04:46 AM4/9/14
to ddd...@googlegroups.com
The common way of versioning an aggregate is by counting its number of events. This approach is used in both CommonDomain and in the Lokad CQRS Sample.
Suppose we execute a command that appends 4 events to an aggregate with version 1. As a result, the command execution raises the aggregate's version to 5.
If we request an event store to give us version 3 of this aggregate, we will get it in an inconsistent state, since it was never commited with just 3 events.
To me, it seems more logical to define version of an aggregate by the number of its commits. In this case, the command would raise the version to 2.
Am I missing something?

Greg Young

unread,
Apr 9, 2014, 8:54:39 AM4/9/14
to ddd...@googlegroups.com
Normally when querying the event stream for a retroactive state you would query with a time not a version no? If a time they would all have save time and either all applied or none applied.
--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
Le doute n'est pas une condition agréable, mais la certitude est absurde.

@yreynhout

unread,
Apr 9, 2014, 8:57:46 AM4/9/14
to ddd...@googlegroups.com
Either count your commits or count your events. The event store does not return aggregates, it returns streams. As such, just loads up event streams or a stream of commits (depends on the lib/product we're talking about), and then just initialize your aggregates with events up to version 3.
Reply all
Reply to author
Forward
0 new messages