Abuse #1
“I’m using CQRS because I need to scale.”
While CQRS may be more scalable than other more traditional architectures, the use of asynchronous communication often complicates the user interaction model causing users to not see the changes they made to data in the UI until later. Trying to compensate for this (by writing even more code) digs one deeper into the complexity hole.
When I point to non-collaborative subdomains and state “You don’t need CQRS for that”, the reason is that in these areas you don’t tend to have much read/write contention. While multiple users/actors may be working in parallel, they don’t touch the same set of data (or do so only very rarely).
In these environments, all you need is a scalable data storage technology – something designed to scale-out (unlike most relational databases). This can take the form of NOSQL databases like HBase and Cassandra. Often all you need is the UI to query that directly and show the results, and the same goes for persisting the data back – possibly with some basic validation and calculation code on the side.
No commands, events, DTOs, publish/subscribe, domain model, etc.
As Ayende says – JFHCI, just f-ing hard code it.
You’d be surprised how much of your data this approach can apply to.
With the time you save on all the less important stuff, you’ll have more time to apply CQRS the right way for the high-value/high-complexity parts of your system.
***
Just a final note, as registration for my course in New York is coming to a close in 2 weeks, I wanted to let you all know that the price for the course will be going up this April, after the course in Sydney. The reason for this is that the courses I run myself (at the current rate) have been cannibalizing attendees from the partner companies I do the course with.
I’ll be providing significant discounts to independent consultants (and others paying their own way) to try to keep things fair. Hope to see you there.