Do not mistake DDD for CQRS. Yeah but where to start?

A quick write about three general concepts that are often mixed up but are not directly related, DDD, CQRS and SOLID.

When I see how newcomers evolve in their approach of CQRS and DDD, I often realize that they are mixing up concepts that should not be!

A quick reminder:

Domain Driven Design

DDD is not a technical pattern, it’s more like a very general approach on how to implement the complexity of a domain in a way that your model really fits the reality and your client language (Ubiquitous Language).

I’d say that it is a really difficult exercise which requires strong experience in building enterprise applications.

It’s not just a bunch of design patterns that you can apply in your code as a set of tools to ease your development. Being a domain model architect is for me a real challenge and certainly can be a full time job.

It’s a way of thinking. After years having implemented really data centric Service Oriented Architectures, it really takes a brainwhashing to start thinking about the model like Eric Evans describes it in his book. And for me, I just scratched the surface, and I have to force myself to forget about my common approach every time I try to think this way.

DDD is definitely not related to CQRS. But CQRS can really help implementing DDD, don’t mix things up.

Command Query Responsibility Segregation (aka CQRS)

CQRS is a pattern, first described by Greg Young, which is really simple in its core concept.

The general idea is to separate read and write operations in an application so you can simplify the read side and potentially scale an application at will, and you can then concentrate in catching the user intent on the write side and unleash the full power of OOP in your domain model.

You can read Fowler’s definition for mode details.

In this way, it’s a big help when trying to implement DDD because it gives you the liberty to model your domain without having your framework or your database in your way.

But again, CQRS is not related to DDD, some (a lot?) implement CQRS along side with DDD, but it’s not a requirement.

Where to start?

When you are new to all this, my advice would be to not try to implement all at once. I think that if you do, you’re doomed to failure.

Concerning DDD, I would personally start by reading Eric Evans’s book, maybe two of three times, and try to gently accommodate with this new way of thinking without wanting absolutely to implement things right away. Be patient.

Reading other architects experiences on the internet is a big help, especially when they talk about how they refactored a legacy model, the best for me.

As for CQRS, this is for me a very different story. This approach is so simple and so efficient that it can be easily implemented, by small touches at first.

Trying to implement CQRS will naturally lead you to ask new questions and to rethink how you can implement your domain models. You will first focus on consistency, on how to refactor your models to benefit from Value Objects and that kind of modeling tools.

And without knowing, you will implement SOLID, maybe for the first time in your life (I mean, really), and I think that will naturally lead you to DDD and will help you slowly understanding the key concepts behind it, simply because you won’t focus on tweaking your framework anymore but on the real stuff!

You maybe even will be more comfortable with hacking the code that is not relevant to the domain model, like in Controllers, Forms, and everything that doesn’t matter so much (just throwaway code).

Of course, that’s my own vision of things, but it works for me!

Good luck ;-)