2010-08-05 4 views
6

Я следующий сценарий, который мне нужно реализовать по образцу CQRS:CQRS - Eventual Консистенция

  1. пользователь входит в систему
  2. пользователь вводит некоторые страховые детали
  3. пользователь просят решения применяться
  4. пользователь просматривает результат решения

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

Проблема заключается в пользовательском интерфейсе, как я могу сообщить пользователю, что решение применяется, поскольку в CQRS модель чтения не обновляется «сразу», как заставить пользовательский интерфейс показывать, что решение находится в процессе и «скоро» прибудет?

Мне также нужно дать пользователю возможность выйти из системы и войти в систему, так как решение может быть еще не применено, как заставить пользовательский интерфейс отображать «ожидающий экран решения»?

+0

Является ли пользовательский интерфейс веб-клиентом или смарт-клиентом? – stung

+1

Состояние изменено каким-либо образом? Я имею в виду, является ли это решение приложением какой-либо формой вычислений, которая должна быть подтверждена? Если да, то это видимо для «других» в системе? Как этот сценарий отличается высокой степенью сотрудничества? –

ответ

3

IMHO решение будет состоять в том, чтобы ваша команда выдавала событие ApplyForDecisionRequested и событие ApplyForDecisionHandled и соответствующим образом обновляла вашу модель чтения.

7

Ответ заключается в том, чтобы немедленно поднять событие, указывающее, что решение было применено, обновить прочитанный БД и сразу перенаправить на ваш ожидающий экран решения, был ли обновленный БД обновлен к этому времени. Статический текст «В ожидании решения вас свяжут» или что-то в этом роде. Они могут обновляться или возвращаться позже и, скорее всего, получат реальные данные. Затем, когда решение было решено, вы имеете событие DecisionMade и обновляете прочитанный БД, отправляете электронные письма, независимо от того, в каком случае.

Это компромисс с возможной согласованностью, с которой вам приходится иметь дело в CQRS. Часто, когда я вносил изменения в свойства объекта домена в форме, я подделываю его в непосредственной обратной связи, получаемой пользователем, когда задняя часть выполняет свои обязанности. Да, немного уродливые, но пользователи этого не знают.

+2

Хороший ответ, особенно о пользователе, который не знает. Это ключ, убедитесь, что пользователь не заметил. Например, вы можете хранить внутри кеша браузера или сервера, чтобы этот элемент был обновлен. Когда вы получаете доступ к readmodel для данных и в вашем кеше, вы замечаете, что данные еще не обновлены, вы делаете это самостоятельно, но только для этого пользователя. SignalR также отлично подходит для обновления других клиентов как можно быстрее. –

Смежные вопросы