CQRS without Event Sourcing - what are the drawbacks?

Question

Besides missing some of the benefits of Event Sourcing, are there any other drawbacks to adapting an existing architecture to CQRS without the Event Sourcing piece?

I\'m

Answer 1

I completely agree with Dennis, ES is no precondition for CQRS, in fact CQRS on its own is pretty easy to implement and has the potential to really simplify your design.

You can find a smooth introduction to it here

Secondly what benefits does CQRS on its own bring to the table ?

• Simplifies your domain objects, by sucking out all the query concerns
• Makes code scale able, your queries are separated and can be tuned easily
• As you iterate over your product design you can add/remove/change individual commands/queries, instead of dealing with larger structures as a whole (e.g. entities, aggregates, modules).
• Commands and queries produce a well known vocabulary to talk with domain experts. Other architectural patterns (e.g. pipes and filters, actors) use terms and concepts that may be harder to grasp by non-programmers.
• Limits the use of ORM (if you use one), I feel ORM's bring in unwarranted complexity if you try and use them for querying, the abstractions are leaky and heavy, trying to tune them is a night mare :) Using a ORM only on the command side makes things much easier, plain old SQL is the best for queries, probably using a simple library to convert result sets into DTO's is the most you need.

More on how CQRS benefits design can be found here

Also do not forget about the non tangible benefits of CQRS

If you still have your doubts, you may want to read this

We currently use CQRS for projects with medium complexity and have found it be very suitable. We started out using a custom bootstrap code and have now moved on to using the Axon Framework to give us some of the infrastructure components

Feel free to PM me in case you want to know anything more specific.