Is CQRS really only for collaborative domains?

[Willem van Gool]

Hi,

I've been studying on CQRS and DDD-concepts for a while now, and I think it's safe to assume that I understand the basics of the approaches, not only how to apply them but also when (not) to apply them. However, there's one thing I can't really find an answer to in the theory, so I figured I'd just ask it here: is CQRS really only recommended when you have a collaborative domain (and considered over-engineering for all the other cases), or are there other valid arguments to apply a (subset) of the CQRS-techniques in domains of reasonable complexity?

For example, I've read virtually everywhere that if a domain is complex enough (or anticipated to change frequently and/or grow in complexity), DDD might be your friend. In addition, it's highly recommended not to build a domain-model that's also used for querying, thereby avoiding a hybrid model. So in fact it is recommended to separate your business logic side from your query side, basically applying CQRS, if you choose to apply DDD, right? Now if we assume that not every business case that lends itself to be solved elegantly with DDD is a collaborative domain, you can see that you may want to apply CQRS for systems that are not necessarily a collaborative domain.

I can also think of situations where you wouldn't want to apply a full-fledged CQRS-approach, incorporating true asynchronous commands fired from the UI or have to setup and EventStore, but only apply the concepts of CQRS inside a component/service, behind your legacy, non-CQRS WCF-webservice. For example, in my opinion you could simply transform or use the arguments of an RPC-call to perform a (synchronous) call to an internal command-processor, wait for it to return, and then immediately query you're read-model to provide a result. Does not anyone think this would be a valid approach (using CQRS only inside a component for domain-model separation and testability-improvement)?

[Willem van Gool]

Hi,

I've been studying on CQRS and DDD-concepts for a while now, and I think it's safe to assume that I understand the basics of the approaches, not only how to apply them but also when (not) to apply them. However, there's one thing I can't really find an answer to in the theory, so I figured I'd just ask it here: is CQRS really only recommended when you have a collaborative domain (and considered over-engineering for all the other cases), or are there other valid arguments to apply a (subset) of the CQRS-techniques in domains of reasonable complexity?

For example, I've read virtually everywhere that if a domain is complex enough (or anticipated to change frequently and/or grow in complexity), DDD might be your friend. In addition, it's highly recommended not to build a domain-model that's also used for querying, thereby avoiding a hybrid model. So in fact it is recommended to separate your business logic side from your query side, basically applying CQRS, if you choose to apply DDD, right? Now if we assume that not every business case that lends itself to be solved elegantly with DDD is a collaborative domain, you can see that you may want to apply CQRS for systems that are not necessarily a collaborative domain.

I can also think of situations where you wouldn't want to apply a full-fledged CQRS-approach, incorporating true asynchronous commands fired from the UI or have to setup an EventStore, but only apply the concepts of CQRS inside a component/service, behind your legacy, non-CQRS WCF-webservice. For example, in my opinion you could simply transform or use the arguments of a regular RPC-call to perform a (synchronous) call to an internal command-processor, wait for it to return, and then immediately query your read-model (or pick up any domain-events) to provide a result. Does anyone think this would be a valid approach (using CQRS only inside a component for domain-model separation and testability-improvement)?

[Willem van Gool]

Sorry for the double post..somewherek, something went terribly wrong...

[Phillip Cleveland]

   Trying not to beat a dead horse here, CQRS is not DDD, and is not ES. It just so happens that all of those things can work very elegantly together.  I think that I could convincingly argue that if my data access layer is split into IReadStuff and IWriteStuff that I would have "full fledged" CQRS.

  By the way I do not believe there is a hard and fast answer to your question of when it becomes "over engineering". Only that yes there are situations it's viable to us all those technologies in non-collaborative situations and also situations that it's likely dev porn to use them. 

My 2c 

Phil

Sent from my iPad

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Willem van Gool]

Philip, thanks for your response, and I think we're on the same page here. It's not that I personally think that you're doing CQRS only when you're also doing DDD and ES, nor do I think CQRS is only applicable to collaborative domains, but I was asking this because a lot of theory/tutorials out there focus on applying CQRS for collaborative domains, and only few suggest using CQRS 'just as a good pattern when you feel it works for you'. I guess you just confirmed my feeling that you should just decide case by case and be flexible in your design.

[Phil]

   Sorry about the non-committal answer of "case by case".  I know that when I am looking for guidance I want some concrete evidence.  

  What I can say about what I presented as CQRS as possibly being just a split of the data access layer into separate read/write interfaces is that I have started doing that on small projects that are not using ES or DDD.  

  My reasoning is that I find the option of optimizing those paths separately very compelling.  Often times it turns out that I use the same concrete object to implement both read and write interfaces(so I can use the same connection or other expensive asset), but with pretty much no extra work I have made it much easier to change the implementation in the future to optimize reads or writes.

As others say so often YMMV (thanks Yves)

Phil

Phil