Реализация участника повествования¶

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

Идемпотентная обработка командных сообщений¶

Воспользуемся шаблоном идемпотентный потребитель. Участник повествования записывает ID сообщения в события, которые генерируются при его обработке. Прежде чем обновлять агрегат, участник сверяет ID сообщения в событиях и убеждается в том, что он его еще не обрабатывал.

Атомарная отправка ответных сообщений¶

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

1. Когда обработчик команд повествования создает или обновляет агрегат, он делает так, чтобы псевдособытие SagaReplyRequested сохранялось в хранилище вместе с настоящими событиями, сгенерированными агрегатом.
2. Обработчик псевдособытия SagaReplyRequested отправляет ответ в канал ответов оркестратора, используя данные псевдособытия.

На примере сервиса Accounting и команды Authorize.

Комментарии

Комментарии