Comments on: Domain-Driven Design and Command-Query Separation example application

By: Links to Command and Query Responsibility Segregation (CQRS) Pattern Code and Discussions | iLude

Sun, 17 Oct 2010 05:45:26 +0000

[...] is Erik Rozendaal who wrote a lottery example to help train his coworkers. Erik’s code is written in [...]

By: Erik Rozendaal

Erik Rozendaal — Tue, 19 Jan 2010 08:42:12 +0000

@Jonas: I’ve talk to Allard about cqrs4j and will probably meet up soon with him. I’ll also be giving a talk at the next http://www.dddnl.org/ meetup on CRQS (March 9th).

@Colin: Currently this will result in an optimistic locking failure. It was left as an exercise to add command/event conflict detection and resolution. Probably worth a blog post on itself, but the short version is that when a command is received for an older version of an aggregate you can compare the command to all events that have happened. If any of the events is conflicting (lottery drawn, etc) you get an optimistic locking failure. If there are no conflicts (someone else bought a lottery ticket) then you can proceed to process the command.

By: Colin

Colin — Mon, 18 Jan 2010 22:39:23 +0000

Erik,
Recently, I was studying CQRS by your lottery codes.
I got a problem：How to deal with concurrency issues? For example, two users purchasing the same lottery at the same time : )

By: Jonas Van Poucke

Jonas Van Poucke — Wed, 30 Dec 2009 19:10:33 +0000

Hi,

Have you seen http://www.gridshore.nl/2009/12/21/cqrs-made-easy-with-cqrs4j/
as an Open Source Framework (Apache 2 license)?

Maybe you could help get that one at production quality?

Jonas

By: colin

colin — Mon, 28 Dec 2009 09:19:09 +0000

@Erik
I am glad to hear that.

By: Erik Rozendaal

Erik Rozendaal — Mon, 28 Dec 2009 08:12:07 +0000

Hi Colin,

The example application’s “domain” support currently doesn’t support multi-entity aggregates. Obviously, it should and I have some experimental code. Basically each Entity that is part of the same Aggregate gets a reference to the AggregateRoot and reports it’s state change events there.

To reduce the complexity of the AggregateRoot class I moved the tracking of entities and dispatching of events into a separate class called “Aggregate”. I’ll see if I can check in the code into the master branch today.

Regards,
Erik

By: colin

colin — Fri, 25 Dec 2009 02:39:35 +0000

Sorry about the use of c.

By: Colin

Colin — Thu, 24 Dec 2009 22:44:52 +0000

Eric,
Example application let me know a lot about CQRS. Thanks.
But, I have a question. All Entity must extend AggregateRoot, how to differentiate Entity and AggregateRoot? As you know “Aggregate is: Group of Entities & Value Objects; One entity within the aggregate is the aggregate root”.

By: Command and Query Responsibility Segregation « Dotsystems

Command and Query Responsibility Segregation « Dotsystems — Thu, 17 Dec 2009 15:49:44 +0000

[...] Domain-Driven Design and Command-Query Separation example application by Erik Rozendaal (in Java) [...]

By: Erik Rozendaal

Erik Rozendaal — Sat, 05 Dec 2009 10:05:19 +0000

Thanks David. The onEvent method may certainly become a concern when you start handling a lot of events, although this may also be an indication your class starts to do too many things.

I’ve an implementation of AggregateRoot that uses reflection and annotations to automatically invoke the correct handler methods, but for the training example I found it a bit too “magical”. The current onEvent method makes it very clear how events are dispatched internally.

Another approach could be to use the visitor pattern, but again I think this is probably overkill.

Erik