Comments on: CQRS – The Domain Events

By: Elegant Code » CQRS – Trying to make it re-usable

Elegant Code » CQRS – Trying to make it re-usable — Sat, 28 Nov 2009 23:52:21 +0000

[...] I haven’t done anything with the event store yet, I don’t think the functionality will change much from the code in the example project. One thing that will remain the same is the dependency on interfaces, and not on specific implementations. This is obviously because it is good design practices. And it will enable us to mix this new approach and the approach using the BaseAggregateRoot class together with the same event store. The BaseAggregateRoot is discussed in detail here. [...]

By: Mark Nijhof

Mark Nijhof — Mon, 23 Nov 2009 16:17:35 +0000

@Mike Perhaps you want to send me the code? I am currently working on something as well and some more input would be cool.

By: Mike

Mike — Mon, 23 Nov 2009 16:00:53 +0000

I finally got this working (I think). I had decomposed the event provider stuff out of the aggregate root base and the RegisterEvent call accepts a predicate for acceptance during dispatch.

By: Mark Nijhof

Mark Nijhof — Mon, 23 Nov 2009 14:32:27 +0000

@Szymon Pobiega In my personal git repository I have already moved the different base classes to the event store so that the domain is only 'using' them. And it would probably be doable to create some sort of proxy that does some stuff for you automatically without having the inherit from the base class.

By: Mark Nijhof

Mark Nijhof — Mon, 23 Nov 2009 14:29:37 +0000

@Mike Well each Entity in the collection is going to need an unique Id anyway (unique in the collection) so the event needs the Id of the Aggregate Root and it needs the Id of the Entity. So I am looking for a solution where both will be assigned automatically leaning towards what Jonathan suggested. But in the end you need to match Entities by their Id.

By: Reflective Perspective - Chris Alcock » The Morning Brew #482

Reflective Perspective - Chris Alcock » The Morning Brew #482 — Mon, 23 Nov 2009 11:18:30 +0000

[...] CQRS – The Domain Events – Mark Nijhof discusses the role of Domain Events in Command Query Responsibility Segregation code, showing their role in managing the state changes of the aggregate roots [...]

By: Szymon Pobiega

Szymon Pobiega — Mon, 23 Nov 2009 07:28:53 +0000

Great job! Another very nice post. You convinced me to try this approach in practice. One thing I am concerned with is whether this approach is not overemphasizing the infrastructure. I would really like to put all those base classes in a separate library and just use them.

Obviously, it would be _ideal_ to make this model usable witch POCO approach. I really don’t know if it is possible — it is just an idea.

By: Mike

Mike — Mon, 23 Nov 2009 03:48:04 +0000

I have been messing with this and can’t find a very clean way to dispatch to the correct instance given a collection of same-typed entities within an AR. The only solution I can figure is a predicate, maybe comparing an EntityId against the event, that an Entity base class can supply the MessageDispatcher to either accept the event or not. Otherwise, all entities of that type handle the event even when they shouldn’t.

By: Mark Nijhof

Mark Nijhof — Sat, 21 Nov 2009 14:38:58 +0000

@Jonathan Oliver This is an interesting approach, I'll take a look on how I would like to implement something like this.

By: Jonathan Oliver

Jonathan Oliver — Sat, 21 Nov 2009 04:20:13 +0000

One thing that we’ve done is to promote the idea of routing the events inside the aggregate root to a first-class citizen by making it an object. By doing this, we can actually simply a lot of code. Specifically, this “dispatcher” as we call it, can be provided as a constructor parameter to the child entity object. By doing this we gain several advantages:

1. The child can add its own private routes for particular messages directly to the aggregate root dispatcher.
2. The aggregate root’s “Apply” method will handle incrementing the aggregate version for any event (both aggregate and child entity events)–we don’t have to pass around method delegates to increment the aggregate version.
3. The aggregate root’s uncommited event collection will store all of the events from all child entities (this is slightly different from what Greg does).
4. The events in the aggregate root will then contain all child events in the exact order in which they were created–no OrderBy() method required when persisting, no need to iterate through all child objects, and no need to have each child entity track the domain events because the aggregate root is already doing it all.