My team is beginning implementation of a greenfield application, with a requirement for multi-tenancy. I have been doing a large amount of research on patterns for simple scalability, especially on distributed cloud-based infrastructure, and CQRS seems to be the buzzword du jour (going so far as being called “Crack for Architecture Addicts” which I find quite funny). Benefits and pitfalls aside, it is quite hard to find anyone besides Greg Young that has used this idea extensively (or at all) in production apps and can provide real-world guidance for it.
So here are my questions:
1. Does a CQRS architecture accommodate your typical multi-tenant application, or is it better suited for larger scale internal enterprise applications.
2. If you recommend that it is used in this situation, can you provide some from-the-trenches guidance on approaches – especially on things to get right early on, and what aspects should be evolved organically.
3. If anyone has tried and found it too difficult or not realized the benefits, or has strong arguments against it (and recommend sticking to CRUD and tiered design), I would like to know about those experiences as well.
For reference, the application will be written in .NET, and the front end will initially be web based (ASP.NET MVC), potentially being extended to mobile and thick clients. Concurrency, transactional activity, and data volume are all expected to remain relatively low throughout the lifespan of the application (compared to high volume financial apps and the like). For infrastructure, we plan on using Azure.
I have examined the same starting point myself, from an exploratory perspective before embarking on the actual project (we are still awaiting the business funding). In that, my research and opinion formed therefrom is that the multi-tenant axis of the architecture is largely orthogonal to the use of CQRS for the internal design of a coarse grained service. The multi-tenant requirement places additional overarching constraints around how the application segregates the tenants from a security, data, presentation/personalization, deployment/provisioning and scalability viewpoint. CQRS does not really make this better or worse and in my opinion still has value in addressing valuable architectural challenges for the Services. That said, not all Services that loosely collaborate to provide the application need to follow the CQRS pattern either, provided that the loosely coupled architecture chosen does not prohibit its use.