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

Question

Я пытаюсь изучить и применить подход к проектированию CQRS (шаблон и архитектура) к новому проекту, но, похоже, отсутствует ключевой элемент.

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

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

Без завершения проецирования я не могу получить вставленные / обновленные данные и отправить обратно в интерфейс через сокеты в реальном времени. Одним из решений является отправка состояния одного и того же агрегата и агрегата, но в случае объединений, как я могу отправить полные обновления обратно (данные с объединениями) в пользовательский интерфейс?

Answer 1

У вас есть несколько вариантов для обновления пользовательского интерфейса.

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

1. Включите в ответ об успехе некоторую информацию о версии объекта.Включите в модель чтения некоторую информацию о версии и опрашивайте API запросов, пока версия не станет достаточно новой.
2. Включите в ответ об успехе некоторую информацию о версии объекта.Ваш API запросов позволяет вам указывать, что вы хотите, чтобы данные были как минимум той версии (в заголовке, параметре запроса или чем-то еще).Либо вы можете сделать так, чтобы API запроса немедленно возвращал ошибку, если она еще не обновлена, либо вы можете заблокировать ее до тех пор, пока она не обновится (с таймаутом), а затем вернуть обновленные данные.
3. Используйте какую-либо систему уведомлений клиента, такую ​​как веб-сокеты, чтобы уведомлять клиента всякий раз, когда прочитанная модель «подписана» на изменения.Либо уведомление может содержать информацию, которую клиент должен обновить, либо он может сделать другой запрос.

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

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

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