Как обработать модель чтения в CQRS

Question

Мы хотим внедрить cqrs в наш новый дизайн. У нас есть некоторые сомнения в обработке обработчика команд и чтении модели. Мы поняли, что при обработке команд мы должны брать оптимистическую блокировку на aggregateId. Но какой подход следует учитывать при обработке readModels. Должны ли мы взять блокировку на весь readModel или на aggregateId или никогда не брать блокировку при обработке модели чтения.

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

вариант 2 - захватить агрегатный идентификатор. Здесь могут возникнуть две проблемы. если мы берем блокировку aggregateId мудро -> то что, если чтение модели сервера перезапускается. Он не знает, откуда это начинается снова.

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

Надеюсь, что смогу решить мою проблему.

Answer 1

Если вы не обрабатываете события в Readmodel одновременно, блокировка не нужна.Это тот случай, когда у вас есть единственный экземпляр модели чтения, возможный в микросервисе, который запрашивает события и последовательно обрабатывает их.

Если у вас синхронная модель чтения (то есть в том же процессе, что и модель записи /)Агрегируйте), тогда, скорее всего, вам понадобится блокировка.

Важно помнить, что Readmodel, скорее всего, отличается от Writemodel.Может быть много типов Writemodel, события которых проецируются в одной и той же модели чтения.Например, в интернет-магазине вы можете иметь ListOfProducts, который проецирует событие из Vendor и из Product Агрегатов.Это означает, что, когда мы говорим о модели чтения, мы не можем просто ссылаться на «Агрегат», потому что не задействован ни один Агрегат.В случае электронной коммерции, когда мы говорим «Совокупность», мы можем ссылаться на Product Совокупность или Vendor Совокупность.

Но что блокировать?Здесь зависит от технологии базы данных.Вы должны заблокировать самую маленькую затронутую читаемую сущность или коллекцию, которую можно заблокировать.В модели чтения, которая состоит из списка продуктов (читай сущностей, а не агрегатов!), Когда событие, которое затрагивает только один продукт, следует заблокировать только этот продукт (т. Е. ProductTitleRenamed).

Если событие влияетбольше продуктов, то вы должны заблокировать всю коллекцию.Например, VendorWasBlocked влияет на все продукты (он должен удалить все продукты от этого поставщика).

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

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

Answer 2

Например, например, генерируется событие вставки заказа и, благодаря некоторому рабочему процессу / саге, происходило событие обновления заказа.Что, если событие с обновленным порядком наступает первым, а событие с добавленным заказом еще не обработано?

Чтение моделей обычно легче рассуждать, если вы подумаете о том, чтобы они опрашивали упорядоченные последовательности событий, а не реагировали на неупорядоченныеуведомления.

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

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

Блокировка, вероятно, будет зависеть от характера вашего резервного хранилища / кэша.Но оптимистический подход

1. чтение текущего представления
2. вычисление нового представления
3. сравнение и своп

, опять же, обычнолегко рассуждать о.