Т.е понятно что то удобнее, что то нет, но это уже детали реализации

Вообще у агрегата, есть только команды. А для чтения используются модели для чтения, которые неконсистентны относительно текущего состояния.

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

Был опыт хранения в mysql, для каждого агрегата делали табличку.  С 2 полями - even_id и event_data(json произвольный) в целом всё работало хоть и выглядит костыльно

Очень сложная и спорная тема, пока явно не массовая

Похоже на лямбда-архитектуру.

Горячие данные в одном месте хранить, холодные (снэпшоты) в другом. При этом ещё и вся история будет в иммутабельном виде.

Горячие данные можно и в Кафке хранить, если о технике говорить.

Но тогда вопрос, как настраивать политики хранения и восстанавливать консистентность, то есть объединять горячие и холодные данные, снэпшоты и не зафиксированные в снэпшотах события. Чтобы история с event sourcing стала массовой, для этого нужны удобные инструменты, чтобы этот процесс стал прозрачен для разработчиков.

А агрегат - это что? Я понимаю про поток команд на всю систему или на какой-то ее независимый кусок и этот поток и есть source of truth. И честно говоря именно это и считал event sourcing, но ошибался.

Агрегат - как паттерн DDD

Этот поток что-то меняет (вернее, распадается на кучку других потоков, которые что-то меняют), но переповтор (при необходимости) нужно делать именно от этого потока.

А уж хранить снэпшот с историей или нет - вообще проблема репозитория в каком-то смысле.

Нужно мыслить не потоками, а агрегатами. Потоки - это некие "служебные" артефакты, они служат для доставки событий.

Да агрегат в DDD - обычный объект в ООА... Ими и так все думают (ну, кроме апологетов ОРМ и нормализации).

Нет конечно) не обычный. Не могу больше писать, сорри) надеюсь @ASoloschak подключится

Ну, почти обычный )

Изолированный )

Но при чем тут EventSourcing?

Поверь, есть связь) нет времени писать, погугли плиз aggregate event sourcing

Суть в двух словах - The aggregate is a domain-driven-design (DDD) concept that fits well within event sourcing.

А почему, в 2-х словах не получится объяснить

Да, поток событий как источник правды продают продавцы стриминга, но это не единственная точка зрения. Эту идею убивает одна очевидная вещь - события нужно хранить вечно. Если нет, а вечно не получится хранить в брокере (логе), то нужны снэпшоты, и тогда уже всё становится куда сложнее. И чем дольше хранить, тем тяжелее (труднее и дольше) восстанавливать (агрегаты).

Поэтому, нужно различать event store и event sourcing, и даже event store может быть комплексным, каким до конца не понятно

Ну, а при любом решении чем дальше в историю, тем дороже перестройка проекций и прочие операции. Для любой схемы.