(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||1.00|
There are two main mailing groups for those topics:
- http://tech.groups.yahoo.com/group/domaindrivendesign/ - it was founded on Sep 27, 2002 (wow! I didn't expect that...) It has almost 4000 members at the moment and 22957 messages.
- http://groups.google.com/group/dddcqrs - the first message is from Jul 23, 2010. It has 1331 members and 7643 messages.
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. ;)