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 



Monday, February 6, 2012

Changing the mindset - part 4 / 4 - Subtle difference

This is the last article out of the series about changing the mindset. At the beginning we took the Classic approach, and then we introduced three important concepts (in the order):
  1. Domain Driven Design (Modeling the Domain)
  2. Command Query Responsibility Segregation (Segregation of Responsibility)
  3. Event Sourcing (Segregation of Responsibility)
In the previous part we separated our Read and Write Models. We also applied Event Sourcing as a persistence mechanism for Aggregates. We also equipped the Aggregate with behavioral methods only, and got rid of getters.
Everything looks really nice. The Model is clean, verbose, and everything is explicit (as for such a small example). We have one data store for the Write side, and we don’t have to care about distributed transactions. We can even easily provide historical data.

However, if you paste the last piece of code from the previous part to your IDE, you will see that there are many warnings on the fields – "never read locally". You can ignore them and proceed, but you can stay for a moment and think why they appear.

The "aha" moment!

It dawned on me the one day when I was really sleepy. I was making some coffee, while my brain was in the nothing box. And somehow the idea came to my mind - why do I need all those fields?