PB
Всем привет,
кто работал с микросервисами, cqrs + event sourcing, amqp (kafka),
хотелось бы задать несколько вопросов.
Если мы строим архитектуру приложения с использованием паттернов cqrs + event sourcing,
то задействовано будет две базы данных,
a. первая хранит всю историю изменений "события" + snapshot,
b. вторая хранит, последними изменения
1) Допустим я хочу вывести для определенного пользователя, всю историю его транзакий, которые он совершал в течении года, как это можно сделать?
Разве я могу читать из базы, где мы записываем историю всех событий? Ведь говорилось что эта база только для записи!
Поэтому мне не сильно понятно, как такое правильно делать? Может надо сделать какой-нибудь
2) Какие инструменты вы используете для воссоздания всего этого? Ведь просто Kafka будет недостаточно я думаю,
ибо это просто брокер сообщений или все токи Kafka будет достаточно?
Нашел следующие инструменты: Lagom, Axon, Eventuate
кто работал с микросервисами, cqrs + event sourcing, amqp (kafka),
хотелось бы задать несколько вопросов.
Если мы строим архитектуру приложения с использованием паттернов cqrs + event sourcing,
то задействовано будет две базы данных,
a. первая хранит всю историю изменений "события" + snapshot,
b. вторая хранит, последними изменения
1) Допустим я хочу вывести для определенного пользователя, всю историю его транзакий, которые он совершал в течении года, как это можно сделать?
Разве я могу читать из базы, где мы записываем историю всех событий? Ведь говорилось что эта база только для записи!
Поэтому мне не сильно понятно, как такое правильно делать? Может надо сделать какой-нибудь
materialized view ...2) Какие инструменты вы используете для воссоздания всего этого? Ведь просто Kafka будет недостаточно я думаю,
ибо это просто брокер сообщений или все токи Kafka будет достаточно?
Нашел следующие инструменты: Lagom, Axon, Eventuate
Евент - это не история изменения какой-то сущности.
Событие = евент - это факт намерения пользователя. Намерение != конкретные сущности доменной модели. Намерение != история. Оно может являться лишь ТРИГГЕРОМ к появлению/изменению каких-то сущностей или к срабатыванию каких-то процессов.
В частности евент может быть триггером к появлению записи с историей каких-то сущностей. Например записи о начале/конце какой-то транзакции. Таким образом, вы сначала регистрируете намерение пользователя что-то сделать, а лишь потом делаете это.
Эти намерения хранятся, чтобы при их повторной многократной переигровке один за другим вы каждый раз могли получать одно и тоже состояние системы. Где хранить - зависит от объемов и от того, что вы хотите получить.
Хотите иметь возможность переигрывать, например, всю историю за все времена - тогда каждый евент нужно где-то хранить долго. Например, в time series БД (их много и все в той или иной степени работают плохо). Тогда вам нужно будет всю эту историю скормить чему-нибудь, что у вас обрабатывает евенты. Обычно берут любую messaging систему. Кафка - чуть ли не дефолтный вариант, но далеко не единственный.
Если вы хотите переигрывать только условную неделю - достаточно хранилища в топиках кафки. Если у вас другая система обмена сообщениями - скорее всего в ней есть настройки того, сколько и где будут хранится сообщения.
Но опять же, вам ничто не мешает хранить всю историю, но иметь возможность переигрывать лишь прошлую неделю. Эти две задачи между собой ортогональны
Событие = евент - это факт намерения пользователя. Намерение != конкретные сущности доменной модели. Намерение != история. Оно может являться лишь ТРИГГЕРОМ к появлению/изменению каких-то сущностей или к срабатыванию каких-то процессов.
В частности евент может быть триггером к появлению записи с историей каких-то сущностей. Например записи о начале/конце какой-то транзакции. Таким образом, вы сначала регистрируете намерение пользователя что-то сделать, а лишь потом делаете это.
Эти намерения хранятся, чтобы при их повторной многократной переигровке один за другим вы каждый раз могли получать одно и тоже состояние системы. Где хранить - зависит от объемов и от того, что вы хотите получить.
Хотите иметь возможность переигрывать, например, всю историю за все времена - тогда каждый евент нужно где-то хранить долго. Например, в time series БД (их много и все в той или иной степени работают плохо). Тогда вам нужно будет всю эту историю скормить чему-нибудь, что у вас обрабатывает евенты. Обычно берут любую messaging систему. Кафка - чуть ли не дефолтный вариант, но далеко не единственный.
Если вы хотите переигрывать только условную неделю - достаточно хранилища в топиках кафки. Если у вас другая система обмена сообщениями - скорее всего в ней есть настройки того, сколько и где будут хранится сообщения.
Но опять же, вам ничто не мешает хранить всю историю, но иметь возможность переигрывать лишь прошлую неделю. Эти две задачи между собой ортогональны
