Архитектура Multi-Tenant CQRS

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

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

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

ОТВЕТЫ

Ответ 1

Я сам изучил ту же самую отправную точку, с исследовательской точки зрения, прежде чем приступать к фактическому проекту (мы все еще ожидаем финансирования бизнеса). Таким образом, мои исследования и мнения, сформированные из них, заключаются в том, что ось многоуровневой архитектуры в значительной степени ортогональна использованию CQRS для внутреннего проектирования крупнозернистого обслуживания. Требование многопользовательских мест ставит дополнительные всеобъемлющие ограничения в отношении того, как приложение изолирует арендаторов от безопасности, данных, представления/персонализации, развертывания/обеспечения и масштабируемости. CQRS на самом деле не делает это лучше или хуже и, на мой взгляд, все еще имеет значение для решения важных архитектурных задач для Сервисов. Тем не менее, не все Службы, которые свободно сотрудничают для предоставления приложения, должны следовать шаблону CQRS либо при условии, что выбранная архитектура с плохой связью не запрещает ее использование.

Ответ 2

  • Многопользовательская аренда изменит сторону чтения CQRS. Вам нужно будет фильтровать представления и возвращать только данные, связанные с арендатором. И вы столкнетесь с теми же проблемами, используя любую другую архитектуру.
  • Я бы порекомендовал CQRS, потому что это сделает ваше приложение основанным на задачах (а не основанным на CRUD). Это означает, что у вас будут команды, полученные от пользовательского интерфейса, и они будут более значимыми, чем DTO. Если вы хотите написать свое ядро ​​с помощью принципов DDD, попробуйте избежать модели анонимного домена (http://martinfowler.com/bliki/AnemicDomainModel.html). Подход к этому - переместить всю доменную логику в объекты домена. Ваши обработчики команд должны быть очень простыми (аутентифицировать, загружать агрегированный корень, переводить объект команды на вызов метода, если не были выбраны исключения - применить изменения). Стоит посмотреть запись класса Greg (6 часов с половиной): http://cqrsinfo.com/video/ Как сказал Майкл Шимминс, если вы планируете использовать Azure как свою платформу - стоит посмотреть на проект Lokad.CQRS. Я использовал его для реализации одного из наших проектов.
  • CQRS не подходит, если вам действительно нужно простое приложение CRUD (не основано на задачах). CQRS требуют больше времени, чтобы понять принципы для новичков. С другой стороны, это позволит разделить задачи dev между программистами с доменным ядром и менее опытными программистами view- > dto- > ui.

Ответ 3

Я не думаю, что многопользовательский арендатор становится все сложнее/проще с использованием CQRS. У вас есть различные преимущества, если вы используете обмен сообщениями: вы можете вставлять идентификатор арендатора в командах и событиях как данные заголовка, выбирать хранилище событий на основе идентификации, комбинировать многопользовательский с несколькими экземплярами. Тем не менее, спросите себя, является ли ваш домен очень совместным, и у вас есть эксперт по домену... в противном случае вы получите команду /event -cud; -)