AlexShkor Jul 1 2012 at 00:01

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

8 min

181K

Website development*.NET*Designing and refactoring*

+18

Comments 15

amarao Jul 1 2012 at 02:49

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

AlexShkor Jul 3 2012 at 12:37

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

AlexanderByndyu Jul 1 2012 at 08:28

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

asa_idev Jul 1 2012 at 15:17

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

hancharou Jul 2 2012 at 06:57

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

Ruberoid Jul 2 2012 at 12:17

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

-2

VioletTape Jul 2 2012 at 14:37

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

dubenko Jul 3 2012 at 11:36

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

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

AlexShkor Jul 3 2012 at 12:30

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

rbugaev Jul 4 2012 at 11:26

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

AlexShkor Jul 4 2012 at 14:17

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

sky2high0 Feb 21 2018 at 10:28

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

sndr Jun 20 2018 at 09:53

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

noittom Sep 8 2019 at 15:23

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

0x9d8e Apr 30 2021 at 20:31

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

Show the best of all time