Как справиться с ошибкой Aggregate в проектировании, управляемом предметной областью

У меня есть сложная регистрационная форма в веб-приложении. Когда пользователь отправляет эту регистрационную форму, команда отправляется обработчику команд. Это создает агрегат. Затем он будет сохранен в денормализованной базе данных, а также в хранилище событий. Когда эта транзакция выполнена, событие публикуется. Из-за этого события обработчик событий в конечном итоге создаст другой Aggregate.

Регистрация действительно завершена только тогда, когда созданы оба агрегата. Это должно происходить в одном и том же процессе, но у обоих есть своя транзакция. (в конечном итоге соответствует)

Таким образом, теоретически может случиться так, что AggregateOne сохраняется как в денормализованной базе данных, так и в хранилище событий, но AggregateTwo где-то в процессе может вызвать исключение из-за ошибки или ошибки проверки (например: требуется имя пользователя ).

Это означает, что у меня неполная регистрация, потому что сохранилась только половина данных. Но пользователь ожидает увидеть все введенные им данные.

Как решаются подобные проблемы в проектировании, управляемом предметной областью?

Примечание. На самом деле у меня нет сложной регистрационной формы. Это всего лишь пример сценария. Мне просто интересно, как решать подобные проблемы.


domain-driven-design aggregateroot
person w00    schedule 04.03.2018    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

Как вы описали, создание вашего второго агрегата может привести к ошибкам и, таким образом, отклониться от счастливого пути.

Поскольку вы говорите о командах и событиях, я предполагаю, что вы объединили свое мышление о проектировании, ориентированном на предметную область, с концепцией CQRS.

Для этого вам нужен менеджер процессов. Если вы хотите узнать о менеджерах процессов в контексте доменно-ориентированного проектирования и CQRS, вы можете выполнить поиск по терминам Saga или Process Manager.

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

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

Чтобы ваш прогресс работал, вы должны моделировать свои ошибки также как события. Таким образом, ваш второй агрегат может передать команде создания событие SuccessfulCreate или CreationDenied. Технически событие CreationDenied может быть исключением, но вместо этого проще создать событие, связанное с бизнесом.

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

Реакции менеджеров процессов на события, отклоняющиеся от счастливого пути, принято называть компенсациями.

Надеюсь это поможет

person Frank S.    schedule 27.07.2019