Posts tagged CQRS
CQRS is not an option. It is a must-have
Feb 16th
I am breaking my Monday- Thursday posting habit because of an important post by Greg Young. Why do I think it is important? Because Greg, in a very convincing way, proves that CQRS scenarios do not imply any additional work compared to classic ones.
I have written about this before (here 
and here 
) from the perspective of a single DTO object used to display some data. My point was that DTO is only one of the possible solutions to the problem of displaying data and, compared to CQRS, is in most cases not the best one.
How long will it take to convince people that reads and writes are separate responsibilities and should not be backed by a single normalized database? Using CQRS in DDD in not an option. CQRS is a must-have. And even if you don’t name it explicitly, but you model it well, you will end up having in implicit CQRS.
DDDSample 0.6
Jan 29th
DDDSample.Net version 0.6 have just been released here on CodePlex. Minor changes include moving from in-memory database fakes and SQLExpress to SQLite in both tests and UI.
This finally frees the project from any external dependencies which need to be installed separately. SQLExpress caused many problems so I am very happy I managed to get rid of it. One disadvantage of SQLite is that when working in in-memory mode, it loses all data after closing connection. In thin client scenario where I want to have connection per request this is unacceptable and forced me to use SQLite in file mode. This means that, unfortunately, you have to manually add IIS account write privileges to App_Data directory in DDDSample.Net instalation folder.
The major change is including CQRS (Command and Query Responsibility Segregation) variant of the solution. CQRS is about separating application architecture into two subsystems: one for processing commands and one for processing queries. Command processing uses Domain Model to capture business logic of the problem domain. In classic solution the same model is used to populate the UI which makes it polluted with lots of UI related code. In CQRS, however, Domain Model have only one purpose — support command processing. UI queries (as well as complicated reporting queries) are processed by the other subsystem which can (and should) be optimized for reading (which could mean, for example, suing star schema).
CQRS comes in many different flavors regarding implementation. The most import ones come from Udi Dahan and Greg Young (which is best described by Mark Nijhof). My own implementation is somewhat close to Udi’s ideas (at least I hope so;-). What I haven’t done (yet) is describing commands as separate classes.
Please download the source code and compare the old (classic) implementation with the new one. Any ideas what can be done better?
