Introduction

The concept behind CQRS is neat: detach your domain implementation completely from your representation requirements. I even wrote a framework for it as a learning tool so somebody without any prior experience should be able to boot a CQRS app in a few minutes.

The main idea behind this framework is providing developers new to CQRS an operating room where they can compose their own little CQRS Frankenstein app.

The whole framework is constructed in a way that it forces you to make your domain implementation completely persistence ignorant, respecting typical AR/transactional boundaries.

Scritchy is not "the framework to write CQRS apps"; Scritchy is a framework that tries to provide you a learning platform where you can start grasping the basic principles, advantages and disadvantages in using CQRS.

Once you understand the basic principles behind the CQRS setup, and why everything is setup the way it is, I would advise anybody to gradually replace parts of the framework and just opt for whatever approach you like, using proper message busses, pub/sub/...

If you write your app following the conventions Scritchy dictates, the only thing you need to change to remove the Scritchy dependency is the base object your Aggregate Root inherits from; that is the only dependency that is ever necessary in you app implementation. This was by design, to make future migrations as easy as possible.

I wrote this framework to enable a dev new to CQRS to get his app up and running in a few minutes... But apparently, that is not enough....

Once Upon A Time At A Certain Newsgroup...

There has been a huge discussion over at the CQRS newsgroup about whether a CQRS framework has a "raison d'être". I think it has, as a learning tool, some disagree; I'm fine with that:

What I find really odd however, is that white coats are now starting to draw "MetaSchema's" or whatever the **** they call them, complicating and abstracting a very simple concept even more then necessary.

As an answer to that, I wrapped up a basic app in a few hours which demonstrated about what I think CQRS is in it's core concept, i.e., make a CQRS app as simple as possible, only abstracting what you absolutely have to...

This is the answer I got:

It is unfortunate that people learn programming without meeting the basic tenets of structured programming. Programming with procedures (your commands and queries) has been here from more than 30 decades, some are commands others are queries. CQS is usually applied here too!

ROFL !! Talk about missing the point!! Anyway, after all these fruitless attempts, I decided to invest my time in some things more productive and get away from all these semantic meta-level blahblahblah....

CQRS - The Essence IMO - How Would You Explain It to a 10-year Old ?

All those neat diagrams perfectly aligned and perfectly abstracting away everything in CQRS usually give me the shivers, which is why I started writing this article in the first place. I think Rob Ashton's article was a great attempt, but still a bit to complicated.

One of my current occupations as an ICT generalist is giving strategic ICT advice. Every time we talk about customer interaction/transferring your intent to your customers, I suggest them to interact with their customers as if they were 10-year-olds as an exercise, in order to get to the essence of their intent... So I decided to dogfood this approach, and here is my attempt to explain CQRS to my 10-year-old audience:

That is all there is to CQRS IMO, nothing more, nothing less.

(For all the font freaks, the typeface used in this graph is MouseDrawn™, which will be available for ordering soon, SRP 10K€ ;) ).

Conclusion

CQRS is a neat concept, and applying it gives you all kinds of advantages... But there is no need to make it more complicated then it is; in essence it is just about separating your domain implementation from your UI representation, nothing more, nothing less.

I feel a lot of people are getting confused when they try to get started with CQRS. There is no need to; just separate your UI/domain implementation and UI representation.

People interested in the absolute minimum required to do CQRS, I suggest to take a look at my example app over at github. I would advise Scritchy to people who want to experiment with CQRS for the first time and want a proper app architecture (nuget available). For others - the more experienced people - I suggest you opt for whatever you think is appropriate, as CQRS is not about components, it is about a concept.

Continuous Thinking: CQRS Explained to a 10-year Old