Event sourcing in DDDSample: reviewing Mark Nijhof’s solution
As CQRS version of DDDSample is getting mature, I am switching my development efforts to event sourcing support. For those of you who don’t know that yet, event sourcing is a pattern which encourages persisting not snapshots of data in particular moments in time, but rather events which describe how these data changes. Then, data snapshots (not only the latest, but also historic ones) can be reconstructed by applying these events starting from the ‘beginning of time’. More about defining event sourcing and CQRS can be found here.
I’ve started by looking at Marc Nijhof’s excellent series of posts (starting here) describing event sourcing. Mark has built a sample application based on what he had learnt about CQRS during Greg Young’s course.
Mark’s solution is fairly simple. In the core there is a domain assembly containing classes that model domain concepts like Account and Client. These inherit and use additional infrastructure assemblies which provide event sourcing features.
One thing that looks odd to me is usage of memento pattern to store snapshots of aggregates. I don’t understand why can’t they (the aggregates) be simply serialized as they are. Maybe there is a reason behind this, but I don’t see it, at least for now. I marked this area for further investigation.
Moving away from the core, there are several supporting assemblies which contain commands, command handlers, events and so on. Personally, I don’t see a point in separating some of them. There is an obvious reason why commands and command handlers are in separate assemblies, but the events? They are part of the domain model, at least for me.
After more careful analysis I noticed that there is no notion of messages in Marks sample solution. The events themselves are passed from command side to query side. That is probably the reason why the events are defined in separate assembly — if they are to be used in reporting, it would be nice not to have to reference whole domain model assembly, only the events.
Going further, Mark is using a custom O/RMish solution to implement query/reporting side. I am not a big fan of custom solutions and I probably would use an off-the-shelve one, even if it is slightly more complex then necessary. I am planing to use NHibernate, as in the non-event-sourcing CQRS version.
Anyway, Mark did great job of describing event sourcing concepts to the public. I probably wouldn’t be able to start writing my own implementation in DDDSample without first reading his code. Thanks a lot!
