I’ve been looking at CQRS a lot recently, whether through the blogs of Udi Dahan and Greg Young, podcasts like the Distributed Podcast, or videos on Vimeo, and all sorts of material on CqrsInfo.com. I’m trying to learn as much as possible about it because I feel it has many benefits but with the caveat that it requires careful consideration about when and where to apply it. Everywhere you turn to on the internet seems to be pushing CQRS as the answer to all our problems with frameworks popping up all over. In truth, I think whilst each individual component part looks so simple to comprehend, when taken as a whole, there is a lot more complexity for the “average” development team than any traditional N-tier approach they already know.
It’s easy to get swept away on the tide (I’m looking at myself here) as everyone gets excited and starts going down the CQRS road. I’m writing this so I can come back and reign myself in when I feel I’m edging towards making something more complex than I ought to. I aim to keep learning as much about it as possible so I can make the right decisions at the right time but I need a voice of reason nagging me to ensure I don’t get carried away. Don’t get me wrong, there are some very useful ideas in CQRS that could be used without going all the way and then there are some that 90% of the time you just won’t need like Event Sourcing (even though technically ES is not part of CQRS anyway but everyone writes as though it is).
All I’m saying is that whilst there’s a lot to learn and love about CQRS, do it with a cool head. We can’t all be as clever as Udi or Greg. We should be careful when deciding that CQRS solves our current set of problems that we aren’t trading those for a new set that we’re considerably less experienced at solving.