CQRS: сложный обработчик событий со службой запросов или поиска

Question

Я считаю, что общее руководство по обработчикам событий, которые заполняют модели чтения / проекции, состоит в том, чтобы сделать их простыми.

Каково руководство по выполнению запроса из обработчика событий или, предпочтительно, с использованием службы домена поиска который возвращает некоторую информацию, необходимую для представления?

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

• Вариант 1: Мы могли бы выполнить поиск в обработчике команд и добавить его к событию по мере его публикации. Это означает, что обработчик команд должен использовать доменную службу исключительно для заполнения события, а значение может нуждаться в передаче в модель записи, которая вызывает указанное событие. На мой взгляд, это загрязняет модель записи, которой я бы хотел избежать. Для меня это наименее благоприятный вариант.

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

• Вариант 3: Поиск выполняется в обработчик запросов и в сочетании с представлением при запросе. Риск: усложняет обработчик запросов и добавляет снижение производительности в точке чтения, а не на этапе записи / события.

Любой предыдущий опыт, который заставлял кого-либо советовать один из этих вариантов по другой

Answer 1

Вариант 2 является обычным выбором в литературе - мы запускаем асинхронный процесс, который собирает значения из одного или нескольких постоянных хранилищ и создает новое представление, которое кэшируется для использования вашими сценариями только для чтения.

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

Риски: добавляет чтение БД (через службу домена) в обработчик событий, что создает дополнительную потенциальную точку отказа.

И что? мы просто потерпим неудачу и повторим попытку позже. Наши представления только для чтения в любом случае являются устаревшими копиями; любой, кто ожидает задержку в наносекунду или выше, шутит сам.

Иными словами, нас не волнует сбой, нас волнует то, что мы достигаем наших целей уровня обслуживания и как быстро мы сокращаем наш бюджет ошибок.

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

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