Межсовокупная коммуникация в CQRS + DDD + определение источника события
Однако мне интересно, как мне следует обрабатывать сценарии, когда пользователи вводят значения для обоих.
blockquote>Вы можете рассматривать типы медиа как аналог.
То есть, предположим, что у нас была спецификация для
application/vnd.example.AorB+json, которая определяла поле A, поле B и явно выражала, что должен присутствовать ровно один из этих двух вариантов.Теперь, когда наша конечная точка получает POST или PUT с типом содержимого
application/vnd.example.AorB+json, мы знаем, что сущность, включенная в тело запроса, должна быть документом json с дополнительными ограничениями на ключи и значения. [1110 ]Таким образом, по аналогии, если ключи и значения неверны, наша конечная точка должна отклонить документ так же, как если бы сама структура JSON не была правильно сформирована.
Если вы купите эту логику, то практический ответ - развернуть конечную точку, которая ожидает json, отправить что-то сломанное и посмотреть, какой ответ вы получите. Затем смоделируйте свой собственный дизайн на этом.
Стандарт WebDAV имеет интересное обсуждение, связанное с его определением кода состояния 422 .
Код состояния 422 (Unprocessable Entity) означает, что сервер понимает тип содержимого объекта запроса (следовательно, код состояния 415 (Unsupported Media Type) является неподходящим), и синтаксис объекта запроса является правильным ( таким образом, код состояния 400 (неправильный запрос) не подходит), но он не смог обработать содержащиеся в нем инструкции.
blockquote>Таким образом, вы можете посмотреть на свою ситуацию и попытаться решить, является ли включение обоих элементов «синтаксически правильным» или нет, и выбрать соответствующий код состояния.
На практике , это действительно не имеет большого значения. Вы ДОЛЖНЫ объяснить конкретную проблему в теле ответа , чтобы люди могли понять, что произошло. Различные коды состояния на самом деле являются метаданными, так что универсальные компоненты могут выяснить, что делать, но в стандарте нет ничего, что указывало бы универсальным компонентам обрабатывать
422иначе, чем400.Так что не переусердствуйте.
2 ответа
Совокупные корневые границы определяют границу согласованности. Внутри агрегата последовательность гарантирована. Снаружи ... это не так. Таким образом, у вас не должно быть операций, которые охватывают несколько агрегатов и должны быть согласованными. Если вам нужна транзакция, охватывающая два агрегата, вам следует проверить границы агрегатов.
Для событий, происходящих вне агрегата, у вас должен быть обработчик событий, который будет отправлять команду другим агрегатам. Если логика действий между агрегатами более сложная, вы можете определить процесс, конечный автомат, который будет прослушивать события и отправлять команды агрегатам. Процессы могут использоваться для определения долгосрочных транзакций (с компенсацией вместо отката) или для принятия бизнес-решений на основе того, что происходит в системе в больших масштабах (даже между ограниченными контекстами).
При использовании Event Sourcing и CQRS наиболее элегантным (по крайней мере, на мой взгляд) способом взаимодействия между AR является обмен сообщениями. Вы можете взглянуть на проект Ncqrs (это будет проще, если вы парень .NET), особенно ветку «Обмен сообщениями». Идея состоит в том, что AR реализуют интерфейс IMessageHandler для каждого типа сообщений, который они обрабатывают, а базовый класс AR предоставляет метод Send для отправки туда сообщений. С помощью этого API клиенты могут вызывать поведение модели, а сама модель может взаимодействовать (между AR).