Command Query Separation

Command Query Separation is an architectural style which encourages building two separate models for one particular domain. One model is optimized for commands (modifications, like inserts, updates and deletes) and the other is optimized for queries (probably using star, warehouse-like schema).

The goals of CQS are to make both subsystems scale well using methods best suited for each one and to free the command model (which encapsulates the core business logic) from UI related code.

DDDSample is an implementation of sample from Eric Evans' book and, as such, is not using CQS principles. It is that because its purpose is to demonstrate basics of DDD not 'polluted' by derived concepts.

Yet the DDD 'knowledge crunching' process demonstrated in the book by Evans leads to a model which is very well suited for scaling. How is it done?

It is simply because DDDSample (as well as my .NET version) is built according to other good DDD practice--one which says that communication between aggregates is asynchronous. Despite not being named officially as CSQ-driven, DDDSample model has two aggregates representing the same concept (Cargo), one optimized for commands and the other one for queries.

Most of processing-intensive operations of Cargo entity are being done via Handling aggregate which asynchronously pushes notifications into the Cargo aggregate. The latter contains a lot of redundant information which is optimized for searching cargoes and displaying cargo information on the screen.

When I was thinking about future of DDDSample.Net I thought about CQS in the first place. After careful analysis I know it will not give any breaktrough in the field of scalability, but I hope it will make these scalability enabling aspects more explicit in the codebase and will clean up the core business code from presentation concerns.