Click here to Skip to main content
Click here to Skip to main content
Technical Blog

Continuous thinking: CQRS explained to a 10-year old

, 28 Nov 2011 CPOL
Rate this:
Please Sign up or sign in to vote.
The concept behind CQRS is to detach your domain implementation completely from your representation requirements.

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:

duty_calls.png

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 form more then 30 decades,  some are commands other 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/transfering 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:

image.png

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€ Wink | ;) ).

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.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Tom Janssens
Founder Core bvba
Belgium Belgium
Tom Janssens, owner of Core, a software and consultancy company.
Father of two sons named Quinten & Matisse, and married to a beautiful woman named Liesbeth.
 
Blog: http://tojans.me
Github: http://github.com/ToJans
Twitter: http://twitter.com/ToJans
LinkedIn: http://www.linkedin.com/in/tomjanssens

Comments and Discussions

 
GeneralMy vote of 4 Pinmemberlewax0028-Nov-11 11:55 
GeneralRe: My vote of 4 PinmemberTom Janssens17-Dec-11 15:34 
Fair point; will do. Thank you !

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.141220.1 | Last Updated 28 Nov 2011
Article Copyright 2011 by Tom Janssens
Everything else Copyright © CodeProject, 1999-2014
Layout: fixed | fluid