ОТДЫХ ОТВЕТА / ВЫДЕЛЕНИЯ в системе CQRS / ES

Question

Я внедряю систему на основе CQRS / ES с интерфейсом RESTful, который используется веб-приложением.

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

Контекст: POST/profiles { "email": "unique@example.com" }

1. Из моего REST API верните 202 из моего сервиса с указанием местоположения нового ресурса, где мой клиент может запросить его. В этом случае, однако, как я могу обработать ошибки, поскольку в действительности представление не будет существовать или существовать вообще.

2. Создайте сагу по первому запросу, затем отправьте событие. Как только мой сервис создает представление или находит ошибку, результат записывается в сагу. Когда сага будет завершена, верните результат пользователю.

Из этих двух вариантов - второй кажется мне более разумным, если не более сложным. Является ли это жизнеспособным вариантом для построения моделей запросов / ответов RESTful на бэкэнде с источником событий CQRS / ES?

Answer 1

Из моего REST API верните 202 из моего сервиса с указанием местоположения нового ресурса, где мой клиент может запросить его. В этом случае, однако, как я могу обработать ошибки, поскольку в действительности представление не будет существовать или существовать.

Обычный ответ здесь заключается в том, что в качестве части ответа 202 Accepted вы включаете информацию мониторинга

Представление, отправленное с этим ответом, должно описать текущее состояние запроса и указать (или встроить) монитор состояния, который может предоставить пользователю оценку того, когда запрос будет выполнен.

Другими словами, ссылка на ресурс, который изменится при окончательном выполнении принятого запроса.

Таким образом, при описании протокола, в дополнение к ресурсу, который вы создаете, вам также необходимо документировать представление, используемое при переносе работы на потом, и представление, используемое монитором.

Когда сага будет завершена, верните результат пользователю.

В зависимости от работы это может быть излишним.

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

Другой вопрос - как выглядит работа с бизнес-уровня. Если вам потребуется несколько транзакций, чтобы внести изменения, и если вам может понадобиться «отменить» ранее зафиксированные транзакции в некоторых вариантах процесса, тогда имеет смысл сага (или менеджер процессов ).

Set Validation - более широкий термин для применения такого инварианта, как «уникальность» - неудобен. Обязательно изучите и убедитесь, что вы и компания понимаете последствия неудачи.

Answer 2

Да, второе решение лучше подходит для бизнеса.

Насколько я понимаю из вашего случая, с точки зрения DDD создание профиля пользователя - это бизнес-процесс, состоящий из более чем одного шага (проверка уникальности профиля, создание профиль и восстановление из дублированного профиля ситуации). Этот процесс действует как сущность, он запускается, выполняется и заканчивается результатом (успех или ошибка). Будучи сущностью, она имеет идентификатор и может рассматриваться как ресурс REST. Сага будет нести ответственность за его выполнение.

Итак, в ответ на запрос клиента вы отправляете URI ресурса процесса, где клиент может опросить статус. В случае ошибки, он читает сообщение об ошибке. В случае успеха он получает URI своего профиля.

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