CQRS is a philosophy

Posted on March 6, 2012

0


Much has been said about CQRS in the last few months. Leaders in the field have clarified their positions, not everyone liked the conclusion they had come to, poems have been penned about what CQRS actually is, frameworks and libraries have been developed and guidelines are being written. Etc. etc…

For me, CQRS is a philosophy. I know that sounds like BS but in this blog post I aim to explain what CQRS is to me and how it allows me to approach certain aspects of software development in a certain way.

A developer’s first instinct when approaching a new idea, concept or problems tends to be to search for a pattern or, heavens forbid, a framework. (I have opinions on when frameworks should appear in the problem solving process, to be discussed in another blog but I can tell you now – it isn’t first.). When I first encountered CQRS I duly went looking for resoruces and frameworks. There weren’t any. I did find some nice resources on google relating to cars, however, but precious little on CQRS. I am now very glad there weren’t really any good resources at the time. CQRS had been described to me in very loose, general terms and I liked what I heard cause I could understand it. I had just come out after leading my first project, a traumatic one year slog to optimise an awfully slow three-tier winforms/asmx/SQL application. The application serialised heavy domain objects down to the client on each request, we applied DTOs and it performed better but a CRQS style approach would have been even better and possibly less dangerous.

By not having any real resources and frameworks at hand I had to use my own head to think about how and when CQRS might be utilised. The next project I worked on ended up with some aspects of CQRS. The project used asyncronous messaging and we needed the client (a web site) to be able to query (poll) for the state of a particular NServiceBus saga. To do this we emitted some domain and saga data as events and stored the data ‘close’ to the front of the webservice to enable easy querying by the client. This wasn’t deliberate CQRS. Nor was it accidental. It was just the right thing to do, for the given problem. But the fact that ‘it was a bit like CQRS’ somehow made it acceptable for us to store the data in two locations. It allowed us to break the mould.

I think the above cuts to the heart of what CQRS is for me and possibly should be for others too. It’s a wildcard to allow you to approach a problem differently to what has been done in the past. To take a step away from the well trodden path to ‘single-source-of-truth’ hell and do what you know is right.

The Philosophy of CQRS

  • Allow yourself and your team to think differently about how your software deals with data and actions.
  • Accept asynchrony (you might as well, it’s OK).
  • Accept staleness (don’t fight it, feel it?).

Don’t try to pin down or pigeon-hole CQRS but treat it as a loose set of ideas around command and queries, some of which may enhance your software architecture. Just don’t wield it like a hammer.

CQRS isn’t a framework, a pattern or a hymn book. It’s a philosophy. Go sit under a tree for a while.

Videbo vos mox

Advertisements
Tagged: ,
Posted in: Patterns