Шаблон использования для чтения "последних данных" в шаблоне CQRS + источник событий

Я нахожусь в процессе реализации тестового проекта с шаблоном CQRS (Command Query Responsibility Segregation).

У меня есть пара вопросов.

  1. Я хочу проверить последнюю цену в магазине данных для элемента в корзине покупок пользователей непосредственно перед покупкой. Таким образом, цена real_model (через материализованное представление) будет проверена по отношению к самой текущей цене в хранилище данных (таблице product). Я хочу показать пользователю предупреждение, если есть несоответствие между ценой. Каков наилучший способ достичь этого?

  2. Когда пользователь обновляет свою электронную почту и пароль, должен ли он по-прежнему полагаться на создание событий для обновления хранилища данных (Event->EventStore->Service Bus - >DataStore) или непосредственно обновлять хранилище данных? Я не хочу задержки события, запускающего read_model_update, поскольку пользователь должен будет немедленно войти в систему.

1 3
.net cqrs event-sourcing

1 ответ:

Я хочу проверить последнюю цену в магазине данных для элемента в корзине покупок пользователей непосредственно перед покупкой... Каков наилучший способ достичь этого?

Я подозреваю, что "лучший способ достичь этого" будет во многом зависеть от опыта покупок, который ваши заинтересованные стороны хотят предоставить клиенту. Т. е.-когда цена должна быть заблокирована? Например, возможно, цены, показанные в корзине покупок, являются твердыми котировками с ограничениями по времени.

Но извиняюсь за эти подробности...

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

Другой возможностью было бы использовать менеджер процессов; идея заключается в том, что "placeOrder" не является простая запись в модель, но скорее начало жизненного цикла. Итак, представьте себе, например, что ценовое предложение является вещью в вашей модели - когда товар помещается в корзину, генерируется ценовое предложение (возможно, с некоторым сроком действия). При изменении цены обновляются все различные котировки. Когда ордер размещен, обработчик видит событие placedOrder и пытается вызвать метод acceptQuote для котировки цены; если котировка все еще действительна, то генерируется событие продвигает процесс заказа к следующему состоянию. Если цитата больше не действительна, то либо генерируется другое событие, либо команда отклоняется, и в конечном итоге тайм-аут показывает, что может возникнуть проблема....

(Вы можете попробовать сделать что-то подобное с самим продуктом, но это не работает так хорошо из-за проблем с конкуренцией; единственный способ узнать, что вы работаете с Самым последним состоянием объекта, - это записать его в Книгу запись.)

Может быть полезно рассмотреть условия расы не существуют по Уди Дахану.

Когда пользователь обновляет свою электронную почту и пароль, должен ли он по-прежнему полагаться на создание событий для обновления хранилища данных (Event->EventStore->Service Bus - >DataStore) или непосредственно обновлять хранилище данных?

Никаких прямых обновлений - все обновления модели чтения должны произойти-после обновления книги записей.

Я не хочу d

3