Многопользовательская архитектура CQRS - PullRequest
11 голосов
/ 15 декабря 2010

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

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

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

Ответы [ 3 ]

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

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

2 голосов
/ 15 декабря 2010

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

...