Введение в CQRS + Event Sourcing: Часть 1. Основы

[@amarao]

Вот именно вопрос «производительности» мне и интересен. Потому что на простых примерах (когда за IO можно уследить глазками) всё всегда хорошо. Плохо начинается, когда запросы летят десятками тысяч в секунду. Обычная БД скрипит, но терпит. А если мы ведём журнал + head состояния? Пока всё хорошо, всё хорошо. А потом нам надо rebuild и мы стоим перед задачей перемолотить пол-года того, что в нормальном режиме грузило систему на 50%…

[@AlexShkor]

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

[@AlexanderByndyu]

Спасибо большое за статью и главное за выложенный пример. Буду ждать продолжения в серии.

[@asa_idev]

Спасибо за статью!
Ждем продолжения, особенно описание Saga.

[@hancharou]

Большое спасибо за статью. Как раз актуальна эта тема сейчас.
Ждём продолжения!

[@Ruberoid]

Любопытный материал. И все-таки href=«tsya.ru» ться.

[@VioletTape]

Хорошее начало!
Можно далее рассказать об основной проблеме при использовании CQRS + Event Sourcing: Как строить AR и как решать проблему взаимодействия между разными AR.

[@dubenko]

На самом же деле репозиторий не берет из базы готовое состояние агрегата UserAR (AR = Aggregate Root), он выбирает из базы все события которые ассоциируются с этим юзером, и потом воспроизводит их по порядку передавая в метод On() агрегата.

А если событий достаточно много, нагрузка возрастает, какие пути решения? Я так понимаю промежуточное хранение состояния через определенный интервал событий?

[@AlexShkor]

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

[@rbugaev]

Жду описания применения на реальных проектах

[@AlexShkor]

Все будет, Рома, все будет =)

[@sky2high0]

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

[@sndr]

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

[@noittom]

Я не совсем понял, предположим пользователь создан, потом ему 20 раз меняли имя. Чтобы мне получить имя пользователя — будут ли проигрываться все 20 обновлений?
А если при проигрывании будет ошибка?
А если модель данных изменилась, сначала было имя и фамилия, а потом мы добавили отчество и ввели валидацию ?

[@0x9d8e]

Очень похоже на то, что в этом месте придётся оставить отчество необязательным. А местами при изменениях моделей нужно будет писать «миграции», которые точно так-же будут воспроизводиться в нужном месте.
А насчёт получить, как я понял, получаем мы из read-базы уже готовое.