Multi-Tenant CQRS Architecture

Question

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.

Answer 1

1. Multi-tenancy will change a bit CQRS reading side. You will need to filter views and return tenant-related data only. And you will face the same problems using any other architecture.
2. I would recommend CQRS because it will make your application a task-based (not a CRUD based). It means you will have commands received from UI and they will be more meaningful than DTOs. If you want to write your core with DDD principles then try to avoid Anemic Domain Model ( http://martinfowler.com/bliki/AnemicDomainModel.html ). Approach to do this - move all domain-specific logic to domain objects. Your command handlers should be very simple (authenticate, load aggregate root, translate command object to method call, if no exceptions were thrown - apply changes). It's worth to watch Greg's class record (6 hours and a half): http://cqrsinfo.com/video/ As Michael Shimmins said if you plan to use Azure as your platform - it's worth to look at Lokad.CQRS project. I used it to implement one of our projects.
3. CQRS will not fit if you really need simple CRUD application (not task-based). CQRS require more time to understand it's principles for newcomers. On the other side it will allow to separate dev tasks between domain-core programmers and less experienced view->dto->ui programmers.

Answer 2

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.