Поддержание совпадающих корневых ссылок в CQRS. Sagas vs обработчики команд

Я строю прототип для изучения CQRS и источников событий.Поддержание совпадающих корневых ссылок в CQRS. Sagas vs обработчики команд

Скажет, у меня есть 2 корневых заполнители, Организация и Амплуа, один ко многим отношений с необходимостью ссылки на два пути. Позиции могут существовать без организаций (например, фрилансеров).

Для этого обсуждения можно предположить, что были созданы объекты Organization и Position. Теперь у меня есть команда AddPositionToOrganisation.

Убедитесь, что ссылки находятся в синхронизации. Я вижу, у меня есть два варианта.

Обработчик команды Organization может генерировать два события. Один для Организации и один для позиции, добавляющий соответствующие ссылки.
Создайте сагу, которая прослушивает событие PositionAddedOrganisation и создаст файл AddOrganisationToPositionCommand.

Есть ли проблема с использованием обработчика команды Organization для создания событий для позиции? С положительной стороны он группирует связанную функциональность вместе (ссылки), но заставляет Организацию отвечать за некоторую логику позиции.

Некоторое понимание более опытных разработчиков было бы очень желанным.

источник

2016-09-09 Magpie

Нет, я не думаю, что в принципе есть проблема с опцией 1. Для меня всегда своя совокупность, которая должна испускать событие, но если обработчик команды хочет вызвать два агрегата в область действия и выполнить действие на каждый из них принимает эти два события и публикует их вместе в рамках одной транзакции с базой данных, это должно быть хорошо. Я все еще изучаю, как должны быть реализованы системы, основанные на событиях, поэтому я уверен, что кто-то меня исправит! –

Спасибо за ответ. По моему пониманию команды могут ориентироваться только на один агрегат. Обработчики команд проверяют эту команду и создают результирующие события. Агрегаты применяют эти события до их передачи в остальную часть системы. Поэтому мой текущий проект имеет агрегаты, которые также действуют как обработчики команд. Вариант 1 будет иметь организацию, создающую события для позиции (немного вонючие), но она держит логику вместе, а не распространяет ее на 2 обработчика команд. – Magpie

ОК, я никогда не видел, чтобы это говорило раньше, что один обработчик команд должен ориентироваться только на один агрегат.На мой взгляд, обработчик команд обычно вызывает вызовы в один агрегат, что приводит только к составлению списка локальных событий, эти события сохраняются в хранилище. Каким будет вред при применении операций ко второму агрегату, а затем сохранение его событий? –

A aggregate определяет границу последовательности; каждая транзакция привязана к одному агрегату. Попытка изменить несколько агрегатов за раз, например, в обработчике команд, идет вразрез с этим советом.

A process manager (сага) идеально подходит для использования в этом случае. Это независимый компонент, который реагирует на события домена в кросс-агрегате, в конечном итоге, последовательно. В своей простейшей форме диспетчер процессов реагирует на события домена и отправляет команды в ответ. Он также может отслеживать состояние, связанное с процессом, для корреляции событий между агрегатами.

Я бы поэтому предложил, чтобы ваш второй подход был предпочтительнее.

Для дальнейшего ознакомления с менеджерами процессов я рекомендую руководство CQRS Journey, написанное корпорацией Microsoft по шаблонам &. Книга Implementing Domain-Driven Design Vaughn Vernon является полезной ссылкой для создания приложения, следующего за архитектурным рисунком CQRS.

источник

2016-09-09 12:51:14

Спасибо, это тот подход, который я принял. Я видел вариант один как короткий отрезок, но был убежден, что это плохая идея. – Magpie

как примечание стороны, я только что прочитал это в шаблонах, принципах и практиках проектирования, основанных на доменах: Иногда бывает хорошей практикой изменять несколько агрегатов внутри транзакции. Но важно знать, почему вначале существуют руководящие принципы, чтобы вы могли знать о последствиях их игнорирования. Когда стоимость возможной согласованности слишком высока, допустимо рассмотреть возможность модификации двух объектов в той же транзакции. Исключительные обстоятельства обычно случаются, когда бизнес говорит вам, что опыт работы с клиентами будет слишком неудовлетворительным ..... –

Поддержание совпадающих корневых ссылок в CQRS. Sagas vs обработчики команд

ответ

Смежные вопросы