Does any DDD implementation inevitably progress to full-blown CQRS?

[Federico G]

Hello,

I'm getting started with DDD and CQRS concepts. As part of my learning process, I have come to see some implementation challenges repeated in forums, such as were to put validation, how to return validation messages to UI, how to deal with serialization and persistence, all while maintaining a clear separation of concerns, single responsibility principle, and not leaking domain logic nor breaking encapsulation.

My feeling is that most of the responses to these topics on forums and articles are either a compromise of pure principles in favor of pragmatic implementation, or are resolved through a CQRS implementation (or both).

Do you think this is a correct appreciation of the current DDD landscape?
Is CQRS the simplest way to implement a system for a complex domain without sacrificing DDD principles?
Do you have experience of DDD implementations that have lived a long life so far without going the CQRS path?

[Denny Crane]

I think the answers are all going to be highly opinionated.

In my opinion, while the two things share a good deal of synergy in a lot of situations, they are two completely different disciplines. That said, I think:

DDD would benefit greatly from CQRS. I'd even argue that most of the time, a domain-driven project/service SHOULD be done in CQRS unless immediate consistency is a concern.

Conversely, CQRS doesn't necessarily benefit from DDD, as it solves a different kind of problem. CQRS offers independent scalability in that query models are typically under higher load than write models in and can thus be scaled independently of the command model. However, you can have a command model that has no domain. For example, a CRUD application or a worker. A worker would take commands, process some data and save it, and that data would eventually be available through the query model. That command model might lack any real domain-driven concepts and may just be a statistics engine or report service. Or the command model may not have a need for a query model. For example, a workflow engine. In this case, perhaps the service does contain a lot of domain-driven logic but only for the purpose of generating events, thus there is no need for a read model, thus there is no need for CQRS as it is really just a domain-driven worker.

So it really depends on how you're conceptualizing your system. If it's a single application, then it's likely that DDD will show some value and you could end up with the combination DDD+CQRS. If it's a larger system, perhaps it's designed as an SOA or even microservices, in which case, it would depend on which service you're talking about as they could all be designed slightly differently depending on their purpose.