Я читал, что в NServiceBus команды всегда обрабатываются в одном месте. Это общее правило CQRS/event sourcing? Если да, в чем преимущества? Почему это плохая идея для масштабирования узлов обработки команд?Команды всегда обрабатываются в одном месте?
Основная цель обмена сообщениями может помочь нам добиться ослабленной связи между компонентами, поддерживая автономность каждого компонента и логическую «Сервис».
В целом, используя явное присвоение имен, должно быть ясно, что именно вы ожидаете от обработчика сообщений. В сочетании с «принципом единой ответственности» (SRP) мы можем добиться лучшей декомпозиции наших систем. Например, «UpdateUser» ничего не значит, в то время как «UpdateUserPhoneNumber» или «ChangeUserPassword» больше похоже на это :-).
Мы хотим убедиться, что мы не смешиваем логические (например, все это относится к моей «Финансовой службе») и физическому развертываемому сервису (процессу). Могут быть много физических процессов (службы Windows, процессы IIS/WEB, WCF, Desktop), которые содержат части логической «службы» или смешанные логические «службы».
Использование семантики Command/Event разъясняет, какова цель и логическая граница сообщения.
Команды: - Внутренняя связь между компонентами внутри границы логической «Службы» выполняется с использованием команд. - Команды (как следует из названия) могут командовать другим компонентом в пределах границы логической «Службы». - Они изменяют состояние компонента обработки. - Они содержат данные и контекст, необходимые компоненту (обработчику) для выполнения своей задачи. - Команды «Отправлены» (с использованием bus.Send() с использованием NServiceBus) только для одного компонента (обработчик) (один к одному).
События: - События используются для перекрестных логических сообщений «Сервис». - Они уведомляют о событиях, которые произошли в прошлом. - Они легкие и содержат только ссылочные данные, такие как идентификаторы и небольшое количество контекстных данных. - События публикуются (bus.Publish() с использованием NServiceBus) - Существует только один логический издатель и один или несколько подписчиков. - События могут также использоваться внутри логического «Сервиса» между внутренними слабо связанными компонентами.
К резюме: Использование команд с данными внутри вас, логическая граница «Сервис» для изменения состояния. Используйте события со справочными данными для перекрестных логических сообщений «Сервис». Следуйте принципу единой ответственности, это поможет уменьшить размер ваших подразделений. Редукционная муфта - наша цель.
Это имеет смысл?
Команда представляет собой цель изменить конкретную часть сведения о состоянии дел. Имеет смысл иметь только один обработчик команд в одном месте, где реализована эта функциональность. Кроме того, внутри обработчика команд мы реализуем бизнес-прецедент, который имеет свою собственную модель и границы.
Вы можете масштабировать командные обработчики, добавляя больше конечных точек, но это тот же самый код работает параллельно, и это рискованное дело, особенно в распределенных приложениях. Это проще и дешевле масштабировать по вертикали, но я бы сказал, что очень мало типов приложений необходимо масштабировать командную часть.
Я бы не сказал, что масштабирование является «рискованным» - по крайней мере, не в NServiceBus. –
смотрите здесь. ваш вопрос является дубликатом http://stackoverflow.com/questions/21565202/cqrs-single-command-handler – Fran