В CQRS/Eventsourcing, который лучше всего подходит для родителя, чтобы изменить состояние всех его детей ??

Question

USECASE: Предположим, у меня есть следующие агрегаты

• Корневая агрегат - CustomerRootAggregate (управляет каждой CustomerAggregate)
• Ребенок совокупность корня совокупного - CustomerAggregate (есть 10 клиентов)

Вопрос: Как отправить DisableCustomer комм. и всем 10 CustomerAggregate, чтобы обновить состояние, которое будет отключено?

customerState.enabled = false 

Решения: Поскольку CQRS не позволяет стороне записи для запроса на стороне чтения, чтобы получить список идентификаторов CustomerAggregate Я думал следующее:

1. CustomerRootAggregate всегда хранить идентификаторы всех это CustomerAggregate в базе данных как json. Когда команда для DisableAllCustomers принимается CustomerRootAggregate, она будет извлекать команду CustomerIds json и отправлять команду DisableCustomer всем дочерним элементам, где каждый ребенок будет восстанавливать свое состояние перед применением команды DisableCustomer. Но это означает, что мне придется поддерживать последовательность CustomerIds json.
2. Клиент (браузер - пользовательский интерфейс) должен всегда отправлять список CustomerIds для применения DisableCustomer. Но это будет проблематично для базы данных с тысячами клиентов.
3. В интерфейсе REST API Layer проверьте команду DisableAllCustomers и извлеките все идентификаторы со стороны чтения и отправите DisableAllCustomers (ids) с идентификаторами, заполненными для записи.

Какой рекомендуемый подход или лучший подход?

Answer 1

• Корневая агрегат - CustomerRootAggregate (управляет каждой CustomerAggregate)
• Детский агрегат Корня агрегат - CustomerAggregate (есть 10 клиентов)

Для начала, Язык «дочерний агрегат» немного запутан. Ваша модель включает «родительский» объект, который содержит прямую ссылку на «дочерний» объект, тогда оба этих объекта должны быть частью одного и того же агрегата.

Однако у вас может быть агрегат Customer для каждого клиента и агрегат CustomerSet, который управляет коллекцией Id.

Как отправить команду DisableCustomer всем 10 CustomerAggregate для обновления состояния, которое необходимо отключить?

Обычный ответ заключается в том, что вы запускаете запрос, чтобы отключить набор клиентов, а затем отправляете команду disableCustomer каждому.

Итак, как 3, так и 2 являются разумными ответами, с оговоркой, что вам нужно рассмотреть, какие ваши требования, если некоторые из команд DisableCustomer терпят неудачу.

2, в частности, является соблазнительным, поскольку он четко формулирует, что клиент (оператор-человек) описывает задачу, которую приложение затем переводит в команды, выполняемые моделью домена.

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

Когда команда для DisableAllCustomers получает CustomerRootAggregate он будет получать CustomerIds JSON и отправить DisableCustomer команду всех детей, где каждый ребенок будет восстановить его состояние до применения DisableCustomer команды. Но это означает, что мне придется поддерживать последовательность CustomerIds json.

Это близко к правильной идее, но не совсем там. Вы отправляете команду в совокупную совокупность. Если он принимает команду, он создает событие, которое описывает идентификаторы клиентов, которые будут отключены. Это событие домена сохраняется как часть потока событий совокупной совокупности.

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

Но это куча дополнительной работы, чтобы сделать это именно так. Обычная мудрость предполагает, что вы обычно должны начинать с предположения, что подход менеджера процессов не нужен, и только вводите его, если это требует бизнес. «Преждевременная автоматизация - это корень всего зла» или что-то в этом роде.