Udi Dahan - When to Avoid CQRS

[Zach Cox]

After the awesome Building Event-Driven Infrastructure in Scala talk at the meetup on Wednesday, I found this article by Udi Dahan:

http://www.udidahan.com/2011/04/22/when-to-avoid-cqrs

Would love to hear any thoughts on that article from the T8 guys.

Thanks,
Zach

[Nate Buwalda]

While I appreciate his candor, anyone who ends a blog post with "come take my course and I'll tell you why you're wrong" annoys the hell out of me. 

That being said, I agree that ES/CQRS is arch overkill for a majority of applications out there. But using some concepts from it can certainly improve the flexibility of N-tier apps.

Strongly disagree with his put it all in one layer argument. That just makes a sprawling giant mess. I've dealt with archs like that. They remind me of amoebas, just flowing aimlessly all over the place. 

Nate

[Wade Arnold]

Three tier architectures with MVC/MVP/V-VM-M are all 90% of systems do
that are a system of record. I have a state, I want to put a lock on
that state and manipulate the record, I want to display the record in a
list, graph, form. The edge case is only reporting. This goes back to my
comment that you don't need a lot of this stuff if you can run your web
application on a virtualized server.

When you have data streams, workflows, and lots of CPU's and want to
take advantage of distributed systems in those workflows think of your
atomta theory class; then think CQRS.

Wade

[Ben Metz]

[I should mention that I didn't and won't watch Udi, so I don't know what he is saying]

My personal opinion is that CQRS is deeply rooted in solving distributed computing problems.  

People have been separating Reads and Writes for a long time when they have to start dealing with scale.  If you're caching anything, your technically doing CQRS.  Why was memcached created?  Because Brad Fitzpatrick was having difficulty scaling LiveJournal... that was 2003.   But I digress...

Also, CQRS is now often lumped into Event Driven Architecture.  However, you can use the idea of EDA to solve many kinds of problems with much cleaner abstractions in your standard 3 tier architecture without separating Reads and Writes.  

Also you can use things like EventSourcing and EventStorage separately from the idea CQRS... 

IMO, there is a damn lot of rhetoric and religion around this stuff, and really you just need to grind, solve problems, benchmark, iterate and refactor into the correct solution to your problem, all the while...

steal like a fucking artist.

regards,

Ben

T8

[Zach Cox]

Appreciate the responses! I also got the "X is wrong, pay me to learn
what's right" vibe from the post. And agree that we need to learn
about many different approaches and apply the right ones to our own
problems.

Do we need to start an Iowa EDA Enthusiasts meetup group?

[Wade Arnold]

http://blog.xebia.com/2009/10/scala-actors-for-the-enterprise-introducing-the-akka-framework/

I remember reading this two years ago and it changed my view on how to
build large systems forever. Think system of a service rather than
system of record and quickly you start throwing all the SOA ideology
out the door.

wade