CQRS - whats all the fuss about?
Sun Aug 21 2011 by MarkP
If you haven't heard of CQRS - where have you been for the last year to six months? In the .NET world this pattern has been the lastest buzzword that will solve a multitude of issues (apparently) in relation to architectural and software design that has grown out of n-tier architecture. Its premise is to simplify the complexity inherent now in most systems based on this architecture especially when changes are required that tend to impact code in all the various layers. It also faciliates best practice (Single Responsibility Principle) and should lead to better performing systems.
CQRS - is an acronym for Command Query Responsibility Segregation or in laymens terms splitting the database reads (querying) from the CUD (Create/Update/Delete) commands using a messaging system. This is an architecture based around CQS (Command Query Seperation) where methods should either be a command that performs an action or query that returns data not both. The beauty of this architecture is to simplify the querying, as this is based on direct access to unnormalised data that maps directly to the view model objects used in the UI. This in turn simplifies the complexity of the query language to return the data as in most cases you are just returning direct data, so "SELECT * FROM ViewModel WHERE .." would suffice, no more need for complex object graphs or mapping relational data objects to DTO objects via a layered architecture.
The Command aspect of the architecture is slightly more difficult to grasp, but in general is relates to sending commands to a data store for Inserts/Deletes and Updates. When these commands are sent a messaging system picks up these changes and these changes are published to the Read only database or any other subscribers that require updating based on the event.
So thats the basic theory out of the way (see additional reading for further analysis) but how does this relate to real world applications or when trying to implement the architecture where migrating legacy applications with complex relational data structures? To see how this fits in I have decided to embark on a proof of concept application. The architecture to be used will be built around ASP.NET MVC 3.0 using the Razor view engine, MongoDb for the read only data store and SQL Server 2008 RC 2 for the Command data store. The issue is that we are dealing with a legacy application that has complex relational data which requires migrating so it would be unwise to amemd this structure at this stage. The Commands will be handled using Enitity Framework 4.1, due my knowledge in this area. In relation to the subscriber/publisher messaging mechanism I am still open to ideas on this. I am currently reviewing nServiceBus and will more than likely follow this route.
I am using mongoDb for the read only database as this will allow me to review a noSQL database and also see how scaleable this type of solution is. I looked at other noSQL databases (such as RavenDb and CouchDb) but mongoDb seemed better suited to my purposes. There are many discussions comparing these applications so it worth reading these before making a decision. It is also worth noting that you could just use a relational database or even XML data - it depends on your business case and what type of system you are developing.
My main concerns intially are bulk inserting data to mongoDb from SQL Server 2008. As mongoDb data is formatted as BSON (an extended JSON format to support binary data) I assume that I could easily create some form of routine in SSIS to be able to create this and then insert. From their documentation this is feasible using mongoimport. I am interested to see how the project progresses and to see how it all fits together but I feel its always worth reviewing new patterns (or old patterns revitalised) as soon as you can. The majority of new projects I see coming available require MVC skills now which was not so apparent over a year ago.The same I feel will happen to CQRS as it matures , more and more businesses with see the benefits developing applications over standard n-tier architecture.
After reviewing Udi Dahans' blog post When to avoid CQRS, I may need to review if I require CQRS but theoretically seems to be suited to my business requirements as this stage. As this is only a proof of concept application and is defined to see how this pattern can work in my scenario I still feel it is worthwhile pursuing due to the experience that can be gained and the learning involved. I do think there has been confusion relating to CQRS, and there is concern it has reached "best practice" status. Maybe the reasoning behind this is the fact the n-tier architecture had led to complexity in software and developers/architects are now looking at alternatives to this approach based on the many issues that have arisen over the years when developing this way. My own opinion is that all projects need a specific architectural roadmap and all avenues need to be considered based on the business requirements - i.e. one size does not fit all.