Pull to refresh

Comments 14

Вот именно вопрос «производительности» мне и интересен. Потому что на простых примерах (когда за IO можно уследить глазками) всё всегда хорошо. Плохо начинается, когда запросы летят десятками тысяч в секунду. Обычная БД скрипит, но терпит. А если мы ведём журнал + head состояния? Пока всё хорошо, всё хорошо. А потом нам надо rebuild и мы стоим перед задачей перемолотить пол-года того, что в нормальном режиме грузило систему на 50%…
Да, действительно, если при подобной нагрузке на запись регенерация требует дополнительных оптимизаций. Я обязательно подниму эти вопросы в следующих статьях. Спасибо за отзыв.
Спасибо большое за статью и главное за выложенный пример. Буду ждать продолжения в серии.
Спасибо за статью!
Ждем продолжения, особенно описание Saga.
Большое спасибо за статью. Как раз актуальна эта тема сейчас.
Ждём продолжения!
Хорошее начало!
Можно далее рассказать об основной проблеме при использовании CQRS + Event Sourcing: Как строить AR и как решать проблему взаимодействия между разными AR.
На самом же деле репозиторий не берет из базы готовое состояние агрегата UserAR (AR = Aggregate Root), он выбирает из базы все события которые ассоциируются с этим юзером, и потом воспроизводит их по порядку передавая в метод On() агрегата.

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

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

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

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

Only those users with full accounts are able to leave comments. Log in, please.