PD
Да я тоже...
Size: a a a
2020 January 23
PD
Похоже действительно об одном, но в разных словах
PD
Ага, в рамках твоих рисунков - я про kafka в качестве Command Bus.
AS
Ага, в рамках твоих рисунков - я про kafka в качестве Command Bus.
Рисунки немного о другом. Я хотел пояснить почему использование Kafka в Event Sourcing не совсем релевантно.
GK
АБ
Картинка - огонь
Картинка универсальная)) почти под любую технологию
R
https://link.medium.com/7k18T5czyV тут хорошо объясненно это
А вот тут пишут, что Kafka вполне себе про Event Sourcing
ПА
не пишут
ПА
событийно ориентированные это event driven а не event sourcing
GK
Картинка универсальная)) почти под любую технологию
Поэтому и зашла)
GK
событийно ориентированные это event driven а не event sourcing
Event soucing - это один из паттернов событийного-ориентированной Архитектуры
ПА
событийно ориентированные это event driven а не event sourcing
т.е у тебя может быть система основанная на событиях и реакции на них, это будет event driven.
ПА
а event sourcing это про то что весь жизненный цикл агрегата храниться в событиях, и любое изменение его стейта возможно только как реакция на событие. Ну и возможность получить состояние на любой момент времени посредством воспроизведения всех событий этого агрегата до нужной точки
ПА
Хорошие примеры: - реплей игр, банковские транзакции
PD
Рисунки немного о другом. Я хотел пояснить почему использование Kafka в Event Sourcing не совсем релевантно.
Смотри, меня в этих объяснениях сбивает 'нужно всегда зачитывать всю историю по объекту'. Для меня event sourcing это 'есть возможность повторить историю изменения объекта' и 'история изменений объекта есть главная истинна'.
Отсюда и разный подход.
Можешь объяснить, зачем всегда историю читать?
Отсюда и разный подход.
Можешь объяснить, зачем всегда историю читать?
ПА
Смотри, меня в этих объяснениях сбивает 'нужно всегда зачитывать всю историю по объекту'. Для меня event sourcing это 'есть возможность повторить историю изменения объекта' и 'история изменений объекта есть главная истинна'.
Отсюда и разный подход.
Можешь объяснить, зачем всегда историю читать?
Отсюда и разный подход.
Можешь объяснить, зачем всегда историю читать?
ну "всегда" точно не нужно, иначе бы не придумали проекции и снепшоты
GK
Тема event sourcing до конца не раскрыта, с моей точки зрения.
В том числе, нет зрелых решений, чтобы без костылей и плясок хранить события. Поэтому пока разработчики пробуют разные подходы.
Мы хотим покачать плотно тему event sourcing в чате https://t.me/prodoteada
Но когда будет время правда не понятно. Надеюсь до конца года будет всё-таки фактура, которой можно поделиться
В том числе, нет зрелых решений, чтобы без костылей и плясок хранить события. Поэтому пока разработчики пробуют разные подходы.
Мы хотим покачать плотно тему event sourcing в чате https://t.me/prodoteada
Но когда будет время правда не понятно. Надеюсь до конца года будет всё-таки фактура, которой можно поделиться
AS
Смотри, меня в этих объяснениях сбивает 'нужно всегда зачитывать всю историю по объекту'. Для меня event sourcing это 'есть возможность повторить историю изменения объекта' и 'история изменений объекта есть главная истинна'.
Отсюда и разный подход.
Можешь объяснить, зачем всегда историю читать?
Отсюда и разный подход.
Можешь объяснить, зачем всегда историю читать?
Есть еще snapshot. В этом случае применяются только события пришедшие после. Еще смысл в том, что состояние агрегата <> набор данных
ПА
А мне кажется не так важно как хранить их, главное чтобы можно было получить список событий агрегата в нужном порядке, с определенного момента(события)