Wednesday, February 22, 2012

CQRS vs DDD popularity

Let's imagine a situation. You are a person that has some time and wants to learn something new. You have two options briefly presented: Domain Driven Design on the one hand and Command Query Responsibility Segregation on the other. What would you choose?

(Before you start reading below, understand that I compare those two concepts only theoretically and I am not taking under consideration how they interact with each other)

For me it would be pretty straightforward - DDD of course. Why? I will explain below.

However for most people that I have met I see the opposite... I still cannot fully understand why, but let's try to investigate a little...

What Google says? 

I made some quick investigation in the Google Trends. I typed "cqrs" and "domain driven design". When I typed "ddd" or "command query responsibility segregation" the results were unreliable.

We can see that DDD was first and at the very beginning it was more popular than CQRS ever. But then it started to fall down.

On the other hand, CQRS gains the momentum. It looks like in the middle of the previous year it overtook DDD.

domain driven design 




There are two main mailing groups for those topics:
It looks like the DDD community is bigger, but on the dddcqrs list there is much more messages lastly. Maybe because it grapples the DDD topic a little bit.

The learning curve

OK, so let's return to the primary question. Why people prefer CQRS topic over DDD?

CQRS is really nothing complicated in the very basics. You take Read operations and Write operations and separate them into completely different stacks. You implement them independently and the only one complex thing that you can face is switching your mindset from ORM to Event Sourcing (if you decide to use it)... Of course other more complicated things come in time - scaling, transaction boundaries, etc. - but the learning curve is smooth and rises evenly.

With DDD, on the other hand, it's not easy to start... You have to understand all Building Blocks. You have to understand what Ubiquitous Language is, and why it is so important. You also should read The Blue Book at least three times (as they say). ;)


We are not so Agile as we think we are. Introducing change to our mindset requires a great effort. We, as developers, got used to modeling Anemic Entities and name it greatly: The Model. We like working with them. After all, we used them for so many years... And our code still works! But let me ask here - how hard is to change something in it, or to introduce a new developer to the project? And what about customer satisfaction?

In CQRS you don't have to change your modeling techniques. You still can have Anemic Entities and it will work. Your years of experience won't be wasted.

In DDD you have to admit - "yes, I was an Anemic Modeler. I didn't care about boundaries, responsibilities and implicit concepts. It was so much easier."- Our ego may suffer at the beginning...

Where we look for complexity?

We tend to work with so many frameworks. We like them. If we have some big problem, it usually turns out that we misused some of them. We like spending time in fighting with configurations and browsing source code of open source libraries. We are only developers after all - we like to deal with frameworks, not with business...

In CQRS we can still do this same. We can focus on Hibernate, Spring, or some web framework.

DDD however concentrates on the heart of the problem - on the Domain. We have to leave frameworks a little behind and start to think about Real Business Problems.

Return of Investment

It looks like if we adopt CQRS (in whichever form) we will be able to easily scale our system out, browse through history and other cool stuff. The outcome comes very fast. We have some results almost at hand.

With DDD this time is much longer and you won't observe results on the first sight. The true benefit comes when people starts to understand the Domain. When they get involved into modeling exercises. When they start communicate easily with Domain Experts. The project can get the real momentum after some time. And this time can be painful.


We are lazy. :) Admit it. At least good developer should be. ;)
Once we learn something we want to see the result as fast as possible. Like a kid. I am guessing that this is the reason why we tend to get more excited and see bigger benefits from CQRS than from DDD.

But when we are creating really complex systems, we should be looking a little further. And I would definitely go for learning DDD first, since this is a long-time investment, that will have bigger ROI after all. And maybe because I really like modeling... ;)

And what do you prefer to try first: CQRS or DDD?

At this moment I see the biggest outcome from using them both. CQRS makes DDD much much cleaner. And if you introduce Event Sourcing to them, they literally kick ass. ;)


  1. I also noticed that CQRS was becoming more popular than DDD, even though it kind of derives from it.

    "DDD however concentrates on the heart of the problem - on the Domain. We have to leave frameworks a little behind and start to think about Real Business Problems."

    - Exactly! Most developers love technologies and new frameworks to play with. When Eric came to Paris to present DDD 3 years ago, most questions he's been asked were like "Is there a framework for that?" or "Can we use rule engine for DDD?". It is so easy to focus on tools, and as you say, so hard to refocus on the domain.

    I often have the sad feeling that CQRS is cannibalizing DDD. I got friends who love CQRS and talk about it all the time, but what I can hear is that they always talks about the technical patterns: event handlers and store, sagas, aggregates... When I mention that fact they usually deny and claim they also focus on the domain, yet 10s later they're back talking nothing but technicalities!

    By the way if you have any suggestion on how to better introduce or even "sell" DDD please share it! On my side I noticed that people from the business side were rather receptive to the real DDD value proposition, provided we can reach them.

    1. Hi cyrille,

      Thanks for your valuable notes. ;)

      CQRS actually DOES derive from DDD. At the very begining, when Greg Young was working on it, he called it Distributed Domain Driven Design (DDDD).

      I must agree with you - I have this same feeling about cannibalizing. I can see exactly this same behavior among my friends too.

      I just thought about an analogy.
      Let's say that we are in the rally sports (did you mean cars? :D ). There are drivers, who drive and compete, and mechanics, that provide and repair cars. Mechanics are strictly technical - they work with engines and stuff. Thanks to them, drivers can compete at all. And drivers provides the biggest value (if they win of course). They need different skills. And of course we cannot forget, that business people and the audience loves drivers the most.

      So, just thinking:
      Maybe in DDD vs CQRS is all about beeing driver or mechanic? ;)

  2. To me these are two different tools. Like a fork and a knife ;) You use them when you have a particular need. With DDD you can cut to the heart of complex domains. CQRS on the other hand gives you freedom of choices (on many levels) once you separate your models.

    It's good to have different tools available when you're going to eat something - but when I'm feeling like a snack I would rather go with a fork only or maybe even just use my hands ;) Pork chop, however, may require using both :D


    1. I fully agree with you. It always depends... ;) And if you are eating using hands, you can easily get dirty. ;)

      However, I was not comparing tools, but topics that IT specialists can talk about. The point of this post was that people tend to underestimate DDD in favor of CQRS, because it is easier to technical person to focus on technical problems.