The CQRS architecture has been very hot in the past two years. But by now, I think that the majority of the profession agrees that going all the way is only worthwhile for systems with some very specific requirements. Yet, I believe that the separation of reads and writes in an enterprise system has some interesting advantages. In the past year I have applied this principle to an ASP.NET WebForms project that had nothing to do with web services at all, but gave me a lot of benefits. Even my own initiative, the Silverlight Cookbook, is now based on that. I'd like to get a chance to explain you why I use this technique, why it has become part of my default reference architecture (regardless of the technology), and I'll share some of the advantages and disadvantages of that choice.
2. About Me
• Principal Consultant • Speaker
• 16 years IT experience • Public initiatives
• C++ origins but since – Silverlight Cookbook
2001 addicated to C# – C# Coding Guidelines
• Specialties – Fluent Assertions
– Architecture • Internet
– Scrum/XP – www.dennisdoomen.net
– ALM – DZone MVB
– @ddoomen
8. “CQRS is a simple pattern that strictly
segregates the responsibility of handling
command input into an autonomous
system from the responsibility of handling
side-effect-free query/read access on the
same system.”
CLEMENS VASTERS
9. CQRS = CQS on Architecture Level
Front-End
Sustains
the user
No O/R
intent
conversions Queries Business Actions
Projections Commands
Query Service Command Service Command Handlers
Data Access Layer Domain Model
Optimized Repositories
for querying
Optimized
for
consistency
Changes Relational
Query Store
Database
Query
Store
Synchronous or
asynchronous
10. Scaling Opportunities
Front-End
Querying
Querying
Command Side
Querying
Querying
Query Store
Query Store
Relational
Query Store Database
Query Store
11. Myths of CQRS
• It is an architecture (style)
• It should be used by default
• It requires Event Sourcing
• It requires eventual consistency
• It requires a
bus/queues/asynchrony
• Commands are fire-and-forget
• Solves all concurrency problems
• It is easy
15. Effective Aggregate Design
Model true Design
invariants in Small
consistency Aggregates
boundaries
Reference
Update single other
aggregate per aggregates by
transaction identity
16. How it works
Execute query Front-End Send command
App
Query
Processor Command
Service
Find query handler Find command handler
Registry
Creates
Creates
Query Command Find by ID and/or version
Handler Handler
Invoke method Unit-of-
LINQ, HQL, SQL Work
Domain Send domain event Aggregate
Event Loads
Simple Data Root
Handler
Access Layer Store denormalized
data Store normalized
data
Read DB Write DB
17. WebAPI,
What to use?
WCF,
POCO Front-End WCF,
App POCO
Autofac,
Query Unity,
Processor StructureMap Command
Service
Registry
Query Command
Handler Handler
NHibernate Unit-of-
EF, Dapper Work
Domain
Aggregate
Event
Simple Data Root
Handler
Access Layer
Udi Dahan’s
Domain
Event
Read DB Write DB SQL, Oracle,
SQL, Oracle,
RavenDB, RavenDB,
NoSQL NoSQL
19. Reading Material
• Effective Aggregate Design
http://dddcommunity.org/library/vernon_2011
• Meanwhile…on the command side of my architecture
http://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=91
• Meanwhile…on the query side of my architecture
http://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=92
• Busting some CQRS myths
http://lostechies.com/jimmybogard/2012/08/22/busting-some-cqrs-
myths/
• Free MSDN eBook: Exploring CQRS and Event Sourcing
http://www.microsoft.com/en-us/download/details.aspx?id=34774
Editor's Notes
DisadvantagesNo concurrency; conflicting service requests are simply rejectedStaleness ignored;Scalability limited; No domain verbs; domain model does contain concepts from the domain model, just not the business actionsGranularity DTOs; What operations to expose in your WCF service? What relations to include and when? What domain entities to flatten.Unneccesary DTO conversions; Conversions from/to domain model entities, traversing of relations, eager fatchingConflicting demands; query demands denormalized schema, commands require normalized integer schema
DisadvantagesNo concurrency; conflicting service requests are simply rejectedStaleness ignored;Scalability limited; No domain verbs; domain model does contain concepts from the domain model, just not the business actionsGranularity DTOs; What operations to expose in your WCF service? What relations to include and when? What domain entities to flatten.Unneccesary DTO conversions; Conversions from/to domain model entities, traversing of relations, eager fatchingConflicting demands; query demands denormalized schema, commands require normalized integer schema