ЕС это о том, как ты стейт получаешь

можешь обновлять текущий постоянно, а можешь собирать изменения и потом считать стейт

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

По этому описанию я бы посоветовал RailsEventStore (ну или в виде нашей обвязки https://github.com/palkan/active_event_store).

eventide не советую — это не то, что стоит постепенно внедрять в существующий проект, это скорей для свежих приложений; там свой взгляд на мир (ну по состоянию пары лет назад, но с тех пор я про него почти не слышал); это больше вещь в себе, чем RES

не уверен тут, что ES предполагает, что мы *обязаны* собирать больше одного изменения перед тем, как обновить стейт (ну либо я не так понял мысль)
в теории, мгновенное изменение, это частный случай этого аспекта эвент сорсинга

но в целом как раз этот кейс у нас и появился в одном случае: нам нужно получить некоторые данные за определённый интервал, а потом обновить стейт по ним (не сразу после первых данных)

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

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

а можно расшифровку чтобы погуглить?

Event-Driven Architecture полагаю

походит на правду, пасиб

да

ес это не про асинхронную обработку данных, это про стейт только (ес может быть синхронным и асинхронным, может быть в рамках монолита или сервисной архитектуры)

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

вот это больше похоже на правду, кстати, можешь подробнее рассказать?

> не уверен тут, что ES предполагает, что мы *обязаны* собирать больше одного изменения перед тем, как обновить стейт (ну либо я не так понял мысль)

не, смотри:

у тебя есть два варианта получить состояние. в качестве примера я буду приводить сумму пользователей в системе.

вариант первый, сразу считать информацию:

sum = 0

new_user_count = 2
sum += new_user_count

new_user_count = -1
sum += new_user_count

sum # => 1

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

вариант второй, собирать события связанные с пользователями, а потом считать состояние


event_store = []

event_store << NewUser(…)
event_store << NewUser(…)
event_store << UserDeleted(…)

sum = 0

event_store.each do |event|
 case event.type
 when NewUser
   sum += 1
 when UserDeleted
   sum -= 1
 end
end

sum # => 1

во втором случае ты хранишь только изменения, а когда надо - считаешь стейт за нужное время или набор событий (стейт начальный не всегда пустой может быть)

вот второй случай ЕС как раз, он тебе скорее всего в таком виде не нужен, поэтому можешь сделать первый + лог таблицу, куда изменения для аудита слать будешь

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

ух, лигбез в ЕС за 7 минут, кек

вообще, можешь посмотреть записи стримов моих, там всего 4 часа, зато поймешь всю базу за ЕС

sum = 0

new_user_count = 2
sum += new_user_count

new_user_count = -1
sum += new_user_count

sum # => 1

а, еще, во втором случае ты можешь события получать как синхронно, так и асинхронно, это все не важно на самом деле

важно - event_store + event + projections (штуки которые по событиям стейт собирают)