Введение в 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-базы уже готовое.