Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at
DDD : Command Query Separation as an Architectural Concept

There has been some confusion recently around a recent evolution of DDD, the idea of Command Query Separation (CQS) at the architectural level.

This post is yet again jumping ahead into the “advanced” stuff, so go ahead and skip this if you just want to get the basics down first… those will come soon I promise.

Many of you will be familiar with CQS in it’s original form, Bertrand Meyer presented it as:

“every method should either be a command that performs an action, or a query that returns data to the caller, but not both. In other words, asking a question should not change the answer”

On the method level it is an excellent principle to follow, but Greg Young introduced (at least I heard it from him first) the idea of Command Query Separation at the architectural level. This was also discussed a long time back by such luminaries as Eric Evans and Martin Fowler.

What Does CQS Mean at an Architectural Level

In DDD, as presented by Eric Evans originally, the Repository concept is responsible for abstracting your Entities and Value Objects away from the way they are persisted. To retrieve an Entity, or a set of Entities, you would use a Repository method like .GetAllOutstandingInvoices or pass a Specification into a generic query method.

This is a perfectly viable and valid way of querying your Entities, but it does have some issues around some aspects of an application, these are generally referred to as Reporting issues. Reporting issues may well be reports in the classic database style, or may be such things as user interfaces that require searching, sorting, paging and filtering of data.

The concept of applying CQS at an architectural level says, our Domain and transactional operations will use the Repositories, but for Reporting operations, we will use a separate mechanism. The Command is the Domain operations, the Query is the Reporting operations.

Does This Mean We Have More Than One Set of Data?

Perhaps. For the vast majority of systems this shouldn’t be an issue, whatever sits behind the Repositories can also provide the data for the Reporting side of things. This after all is just an issue of Bounded Context again – we have a separate Bounded Context for Reporting, and as Bounded Contexts have their own code and data access, this Context can encapsulate all read requests, and just read them off the same store that your Repositories in your main Domain do.

For example, your main Domain may be using an ORM like NHibernate sitting behind your Repositories. It will provide a rich mapping from your Entities into the database behind.

Your Reporting Context may well use NHibernate too, but with a simplified model designed for read purposes, or you may even just have an ADO DataReader sitting in the Reporting Context, reading directly from the database that NHibernate is writing to elsewhere.

It is certainly viable to have more than one persistence mechanism however and larger more complex systems may well duplicate data. I can almost hear a bunch of you shouting “Heresy!”.

Duplication of Data

“We spend a great deal of effort maintaining data, maintaining integrity, maintaining consistency, and some fool wants to duplicate this problem all over, now we have two lots of data to manage and synchronise!”

Well, no. When you think about it, this is just data for read purposes. And that means that this data can be a subset or a combination of data from our Domain. It could be created by events being published from the Domain, or it could be created by taking a snapshot of the Domain data.

The only issue that really exists is that this data could be stale or inconsistent – it may be 5 seconds out of date, or 10 seconds, or maybe just 1 second – but this data may not be up to date.

Well, of course it may not be up to date…  but is any of the data in your system really up to date? Even if you just requested it from your Domain, and it appeared on screen, before you hit any key on your keyboard, that data is already stale – by the time you press “update” someone or something else may have modified the data.

Eventually the data may be up to date and consistent, it just may not be the instant you request it.

So yes, the data may be stale, but is that really an issue? (hint: the answer is no)

In Conclusion

It may pay to split your Reporting concerns from your Domain concerns, keeping your Domain clear of ad-hoc reporting concerns, and UI concerns. It may also be far more effort than it is worth if the system does not have either massive numbers of these kinds of queries, or just is not that complex.

However, bear in mind that this is a good option for allowing the Domain to evolve without concerns from other parts of the wider application leaking into it, and is a good tool to have ready when you face this issue.


1) Domain Driven Design: A Step by Step Guide
2) DDD: The Ubiquitous Language
3) DDD: Bounded Contexts
4) DDD: There Is No Database


InfoQ Free eBook : Domain Driven Design Quickly
Domain-Driven Design: Tackling Complexity in the Heart of Software (Eric Evans)

Martin Fowler’s Version: EagerReadDerivation
Value Objects Tags: DDD,Domain Driven Design,Practices and Principles

Posted 02-12-2009 4:40 PM by Jak Charlton



jdn wrote re: DDD : Command Query Separation as an Architectural Concept
on 02-12-2009 12:39 PM

"The only issue that really exists is that this data could be stale or inconsistent – it may be 5 seconds out of date, or 10 seconds, or maybe just 1 second – but this data may not be up to date."

In the SQL Server world, at least, where it is very common to do reporting by use of Replication, this is pretty common, so this part of DDD would actually be old hat (although the twist is in using the Reporting domain for the UI, of course).

Casey wrote re: DDD : Command Query Separation as an Architectural Concept
on 02-12-2009 12:48 PM

Indeed, I was using this back in 1999 to split load .... We had "satellite databases"

There is nothing magically new in DDD just a better formalisation of the ideas

Mike wrote re: DDD : Command Query Separation as an Architectural Concept
on 02-12-2009 2:41 PM

This separation has worked out very well in one of the apps I'm working on where for transactional purposes I can utilise nHibernate and work with a proper domain model and for the read-only reporting aspects I can do what does well, binding data controls, getting the best from both worlds.

DotNetShoutout wrote DDD : Command Query Separation as an Architectural Concept - Casey Charlton - Insane World
on 02-12-2009 3:29 PM

Thank you for submitting this cool story - Trackback from DotNetShoutout

Reflective Perspective - Chris Alcock » The Morning Brew #286 wrote Reflective Perspective - Chris Alcock » The Morning Brew #286
on 02-13-2009 3:29 AM

Pingback from  Reflective Perspective - Chris Alcock  » The Morning Brew #286 wrote DDD command query separation as an architectural concept
on 02-13-2009 10:56 AM

You've been kicked (a good thing) - Trackback from

Daniel Teng wrote Weekly links #1
on 02-15-2009 5:01 AM


new ThoughtStream("Derick Bailey"); wrote Proactive vs Reactive Validation: Don’t We Need Both?
on 02-16-2009 3:12 PM

Update: There’s a wealth of knowledge out there that I just haven’t been aware of until now. Thanks to

Billy McCafferty wrote re: DDD : Command Query Separation as an Architectural Concept
on 07-29-2009 3:59 PM


This idea of separating domain from reporting is a terrific that I will surely employ on my next project.  It would've been a big help for reducing complexity and improving performance on another project that I finished up recently.

Billy McCafferty wrote Speaking at Virtual ALT.NET Tonight
on 11-04-2009 12:21 PM

If you're interested in... Finding out what's new in S#arp Architecture Q3 2009, Hearing about

Billy McCafferty wrote Better Application Services and CQS using S#arp Architecture 1.0 Q3 2009
on 03-05-2010 2:17 PM

Obviously, S#arp Architecture is the bee's knees when it comes to developing ASP.NET MVC applications

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Google Reader or Homepage Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of
Red-Gate Tools For SQL and .NET


SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
NHibernate Profiler
Balsamiq Mockups
JetBrains - ReSharper
Web Sequence Diagrams
Ducksboard<-- NEW Friend!


Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers


Community Server (Commercial Edition)