Retrospective of Greg Young’s Final CQRS and DDD Online Course

I woke up at 4 am so that I could virtually attend via LiveMeeting Greg Young’s final online CQRS and DDD course. While I had some sound issues and had to keep coming back into the session, I can still say: Wow! Greg’s knowledge is excellent and his presentation was great.

You can watch him deliver a similar talk at this Skillsmatter podcast about the business perspectives of this architecture: http://skillsmatter.com/podcast/open-source-dot-net/greg-young-cqrs-event-sourcing-the-business-perspecive

It’s easiest these days for me to learn visually, so in review, here are a couple of slides from another blogger, Dylan Smyth, who blogged about this that summarize the distinction between a CQRS style architecture and a more typical stack:

 

 

 

 

 

 

 

 

Rinat Abdullin has a great diagram on his own blog depicting what Greg also calls the Task-Driven UI:

 

To summarize in my own, short, words:

Typical Architecture

On the left side we have the “typical” architecture which has this kind of interaction model:

1. User clicks a button in a client.
2. Client issues a request to the server, asking for Product with ID 50, for example.
3. Server fetches an entity for Product with ID 50.
4. Server creates a DTO from this entity and sends it to the client.
5. The client modifies this DTO.
6. Client ships the modified DTO back to the server for an update.

CQRS Architecture

He contrasts that the right side, which he says may appear at first to be more complex, but it actually turns out to be simpler and less costly because of the Thin Read Layer in which the operations are optimized for read, not write. This means the translation from data to DTO occurs directly here.

1. User clicks a button in a client.
2. Client issues a read request to the server, asking for Product with ID 50.
3. Server fetches the data for Product with ID 50.
4. Server creates a DTO from this entity and sends it to the client.
5. The client operates on a screen and issues a Command to the server, which is not equivalent with sending a modified DTO back to the server.

An important note here is that the "Event Store” is where the commands are serialized, which does not have to be in a relational database. The De-Normalized Data Cache is where a “view” of data created and stored as a result of the Events being stored.

CQRS Diagram

This is an image that Udi Dahan uses to describe CQRS in his own post Clarified CQRS:

Domain-Driven-DESIGN

He also discussed Domain-Driven-Design after talking about CQRS, but unfortunately I did not hear all of that.

Recommend Resources

In addition to the Skillsmatter podcast above, here are some other recommended links about CQRS:

1. Super Simple CQRS Example from Greg Young: http://codebetter.com/blogs/gregyoung/archive/2010/08/31/super-simple-cqrs-example.aspx
2. Clarified CQRS, Udi Dahan: http://www.udidahan.com/2009/12/09/clarified-cqrs/
3. Udi Dahan on CQRS, DDD, and NServiceBus: http://www.infoq.com/interviews/dahan-cqrs-ddd-nservicebus
4. Command-Query Responsibility Segregation, interview with Udi Dahan: http://www.infoq.com/presentations/Command-Query-Responsibility-Segregation
5. Greg Young Discusses State Transitions in Domain-Driven Design and DDD Best Practices: http://www.infoq.com/interviews/greg-young-ddd