Это просто быстрое решение для презентации, суть же не в этом

VIPER и CQRS не существуют в одном приложении: что первый, что второй - это подходы к организации всего приложения, не какого-то отдельного слоя. SOA является частью CQRS в том числе и в бэкенд-разработке. Код не будет разрастаться, его не будет больше, чем для MVC, если вы правильно используете рассматриваемый подход.

Удивлен что VIPER где-то не используется. Точно помню что в одном из Rambler-овских докладов утверждалось что он применяется/внедряется у вас повсеместно. Если CQRS исключает VIPER, то тема UI не раскрыта (V, R, P из VIPER). SOA как принцип избегания классов с состоянием можно приткнуть куда угодно, но в том виде в каком он преподнесен в соседнем докладе он таки увеличивает код. Там автор предлагает плодить фасады на любой чих. > "его не будет больше, чем для MVC" Вы же сами говорили в докладе про множество мелких классов, разве нет?

VIPER не везде используется. Естественно, выбор архитектуры зависит от времени жизни проекта, уровня команды и еще множества факторов. Думаю, в упомянутом докладе имелось в виду, что все основные (т.е. долгоиграющие) проекты реализованы на VIPER. Это уже правда. Да, про UI я ничего в докладе не говорил. Это не было целью доклада. Наиболее интересным в случае CQRS мне видится использование биндингов и view-models. > Вы же сами говорили в докладе про множество мелких классов, разве нет? Да, будет много мелких классов (команда или запросов). Но в случае с MVC все эти мелкие классы будут "внутри" какого-нибудь сервиса или подобного объекта. Так что количество файлов - да, гораздо больше. Количество строк кода - немного больше.