Aggregate_Projection_Events_QueryDefinition_CommandDefinition.PNG

Background
Despite numerous articles and the favourable experiences of enterprise application developers, CQRS has not caught on as a mainstream development architecture (in the way that, for example, MVC has).

I believe that two things are needed in order to demonstrate the architecture and increase its adoption: (1) examples to demonstrate the advantages of scalability, simplicity, testing and read/write independence and (2) tooling to allow developers rapidly to assemble the CQRS application in a graphical model.

Project Description
A project to create an IDE template, plug ins, documentation and related material to facilitate the rapid creation of CQRS based solutions on Azure

This project is intended to provide a quick start IDE template and plug in and various documentation, techniques and so on to allow the rapid creation of CQRS based projects sitting on Windows Azure.

It will facilitate the code generation of Aggregates (aggregate roots) , Events , Projections , Query Definitions and Command Definitions which will build the underlying model of a CQRS / ES based application. This will mean using Tools and Designers so that the model can be assembled visually inside the IDE.

Recommended reading

CodeProject articles

MSDN Documentation

Similar projects

Source code

The initial source code will be in VB.NET - this decision is based on the premise that this is a learning project and it is considered an easy language for developers to read and understand. It should be relatively simple to convert any code to any other .NET language if desirable.

Boilerplate code generated by the tool will be in either C# or VB.Net - as configured by the developer.

When to use

In my experience, CQRS lends itself to large multi-developer projects that are delivered via an internet based front end or via an automation API (for example a WCF or REST interface) where there is a need to scale the reading and writing independently.

The segregation of the read and write side, and the use of a distinct "definition" class for each handler to use means that development can be done in a highly parallel manner without experiencing "model contention" (the big ball of CRUD ).

Using Azure as a back end lends itself to applications with a non-uniform load (either over time, for example where most updates occur at a particular time of the day or over location where users are connecting from different locations)

Last edited Oct 1, 2015 at 8:12 AM by Merrion, version 15