Надо сразу было так делать

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

Сервисы ради сервисов тоже ж не хочется.

добрый вечер, кто-нить практикует event sourcing?

думаю, что это ко мне

тебе прямо ES, а не event driven?

да, ES. У меня практический вопрос

С фронта на апи передается большой json объект с данными и со вложенными объектами, который создает или апдейтит сущность в бд, а так же апдейтит/создает ассоциации с вложенностью. Вложенность > 1.
Например может быть такая вложенность
Статья -> Контентный блок типа фото галерея -> Изображение фотогалереи
И вот например при апдейте
- изменилось часть полей у статьи,
- изменилась позиция контентного блока в статье
- изменили подпись у узображения
Другими словами поменялись все три сущности
Как принято в ES? Это один эвент или несколько для каждой сущности свой?

это похоже на проблему агрегата

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

по идее, ты можешь одним событием все пихать, а можешь разбить на “энтити” все и их сохранять отдельными событиями

т.е. ответа нет правильного на твой вопрос и все очень зависит от конкретной системы

просто в рельсах удобненьо же когда передаешь ему _destroy + id или _attributes и рельсы тебе неявно всё что надо делают.
так вот получается чтобы собрать один объект со всеми изменениями надо уйти от неявного к явному сохранению при этом проверять каждое поле на предмет изменения вручную?

либо кешировать агрегат в базе данных

если разбить на "энтити" там обзерверами можно в принципе

но хотелось бы целиком

если тебе в “90%” времени нужен только последнее состояние

вобщем я понял что мне видимо не хватает знаний про агрегат, почитаю еще, спасибо!

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

только зачем и какую проблему решить хочешь