Кажется нашёл то что нужно

Спасибо всем

гугли Udi Dahan, Greg Young
а ивенты в базе грубо говоря называется Event Sourcing

ивенты в базе это ивенты в базе, не надо мешать теплое с cqrs.

Не вижу никакой проблемы в том, что я написал. Я человеку подсказываю, в какую сторону гуглить, чтобы он не переизобретал известные подходы. Если он почитает про ES и поймет, что именно это ему и надо, но он не знал, как называется, то это будет хорошо.

Во-вторых ты как-то слово "база" узко понимаешь. В широком смысле база данных — это система хранения информации. И не все бд реляционные. EventStore, Kafka Streams вполне себе базы данных в этом смысле. Я поэтому и добавил "грубо говоря".

Просто уж если приходишь к тому, что надо хранить ивенты на диске, то до ES один шаг остаётся и он может быть логичным и оправданным.

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

Ивент сурсинг нужен там где ивенты сами по себе важны и важен порядок в котором чего происходило. Опасно туда направлять не уточнив достаточно. Я тож когда-то купился - сча аккуратнее это дело советую

Хранить ивенты в базе это просто лог, ивент сурсинг про другое

а если порядок не важен?

ЕС - это же просто персистенс левел. Метод, которым у тебя восстанавливается состояние в памяти из системы хранения

чтобы распакрваить евенты в состояние, тебе надо во первых прочитать эти евенты, а во вторых применить правила бизнес-логика к этим изменениям. Пока же идет обработка евентов как евентов, она значительно быстрее и проще - там не нежно ни применять бизнес-логику, ни даже читать эти евенты. Не стоит тянуть сложность туда, где она никому не сдалась.

чта?) какие бизнес-правила? ивенты - это факты, это то, что случилось. на кой хер к ним бизнес-правила применять?

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

Откуда у тебя в ивентах бизнес значимой штуки взялись невалидные ивенты? Состояние в памяти ты в любом случае восстанавливаешь, не важно из сохраненого ранее стейта, или свежесобранного из событий.
ЕС - не про рассылку сообщений куда-то и зачем-то. Это просто метод хранения состояния бизнес значимой штуки. Всё.
Возможно если начать понимать что такое ЕС и чем оно отличается от message based systems, прости господи за такую формулировку, окажется что не все так страшно.

не "откуда взялись" а "что будет, если они там останутся".
ЕС -  не про рассылку сообщений куда-то и зачем-то, тут я полностью соглашусь. Но текущий контекст как раз про то, как бы до конечного получателя событие из кафки доставить гарантированно.

Нет

`Event sourcing persists the state of a business entity such an Order or a Customer as a sequence of state-changing events. Whenever the state of a business entity changes, a new event is appended to the list of events. Since saving an event is a single operation, it is inherently atomic. The application reconstructs an entity’s current state by replaying the events.`
https://microservices.io/patterns/data/event-sourcing.html

The simplest way to think of using Event Sourcing is to calculate a requested application state by starting from a blank application state and then applying the events to reach the desired state
https://martinfowler.com/eaaDev/EventSourcing.htmlhttps://martinfowler.com/eaaDev/EventSourcing.html

Коллеги, fp и ddd возможно скрестить? Насколько это разумно?

А чего добиться то хочешь, какие проблемы решить?