Introduction

CQRS is one of my architectural pet peeves, as you might have noticed from the numerous amount of blog posts I made on this subject. However, I noticed the concept is complicated and hard to grasp for newcomers to CQRS. I have been spiking numerous attempts of a framework that makes CQRS both more manageable and understandable, failed hundreds of times, and even published a few of my acceptable attempts as gists over at github...

A few days ago I was messing around with SignalR trying to setup again another CQRS attempt, and failed miserably.... However, 2 nights after that approach I had an ephiphany which had been lingering around in my head ever since.

Today I decided to get back to business, so this afternoon I started spiking a proof of concept (POC).

I think you will be happy to see that I managed to get most of the annoyance out of CQRS with this simple concept.

Show me the codez !!!

Before I show you the codes, I would like to mention a few things, since it is a POC:

• My eventstore is currently implemented as a List of objects. While this works for this concept, you can imagine that this might get you into trouble
• The Aggregate roots get completely rebuilt every single time (no cache), so the app might get a litlle bit slow when you push numerous commands to it
• The concept is completely synchronous, but making it asynchronous should be effortless.
• The functionality I talked about in these 3 points are currently implemented as overrides of the abstract class ScratchBus, which requires you to override the function to load an ar, and to replay events on an object. As there are some nice alternatives available, I am not planning on reimplementing them, but for now I opt for the simplest thing that could possibly work.
• I am currently still thinking about conventions for the viewmodels as these conventions need to provide more flexibiltity then just EVENT/AR.ID binding... I am not sure whether I will find an acceptable solution on that matter... Update: KISS as usual, view instances are built/modified by stateless handlers; piece of cake !

This is the only code required to get a fully working AR with events... IMO it looks pretty clean. As you might have guessed there are some conventions used in order to get the plumbing out of the way.

What do you think ? Pretty clean I would assume ?

Sold! Where can I get it ?

Depending on the feedback I get, I might push it online over at my github account, but for now, I would rather try to find a good solution for the viewmodel/event conventions.

Update: I published the sourcecode over at my github account.

Update 2: Whenever I push the source to github, the demo at appharbor gets updated as well automagically.

Feel free to PM me any time (or tweet; @tojans )...

Conclusion

While this is still a work in progress, and nowhere near ready for production usage, I think this might actually be a pretty cool implementation. If I can somehow find a way to complete this framework, I think I might be on to something here.

I am aware that CQRS is considered to complicated by some, and I am aware that some experts advise against the usage of CQRS in most cases. However, it is my opinion that CQRS provides you with a proper template for development, where everything is nicely separated the way it is supposed to be, and easily adjustable. Another motivation for the CQRS approach is the spaghetti-code of the nillies, currently also known as lasagna-code: numerous amounts of layers over layers that make adding a simple field to a screen a few days of work.

By providing Scritchy, I am trying to find a way to make CQRS not only working, but also relatively easy to use and understand.

This is not the end, but the beginning of a new path...