Многопользовательская архитектура CQRS

Моя команда приступает к реализации нового приложения с требованием для мультитенантности. Я провел большое количество исследований шаблонов для простой масштабируемости, особенно в распределенной облачной инфраструктуре, и CQRS кажется модным словом в журнале (доходит до того, что называется «Crack for Architecture Addicts», что я нахожу довольно забавным ). Помимо преимуществ и недостатков, довольно сложно найти кого-либо, кроме Грега Янга, который бы широко (или вообще) использовал эту идею в производственных приложениях и мог бы дать реальное руководство для этого.

Итак, вот мои вопросы: 1. Подходит ли архитектура CQRS для вашего типичного мультитенантного приложения или она лучше подходит для более крупных внутренних корпоративных приложений. 2. Если вы рекомендуете использовать его в этой ситуации, не могли бы вы дать несколько готовых рекомендаций по подходам, особенно в том, что нужно сделать на ранней стадии, и какие аспекты следует развивать органически. 3. Если кто-то пробовал и нашел его слишком сложным или не осознал преимуществ, или имел веские аргументы против этого (и рекомендовал бы придерживаться CRUD и многоуровневого дизайна), я хотел бы также узнать об этом опыте.

Для справки , приложение будет написано на .NET, а интерфейсная часть изначально будет веб-интерфейсом (ASP.NET MVC), который потенциально может быть расширен на мобильные и толстые клиенты. Ожидается, что параллелизм, транзакционная активность и объем данных останутся относительно низкими на протяжении всего срока службы приложения (по сравнению с крупномасштабными финансовыми приложениями и т.п.). Для инфраструктуры мы планируем использовать Azure.