Как обновить пакет данных с помощью Event Sourcing

Question

Мне интересно, как обновить набор данных в концепции Event Sourcing для любого агрегата.

В традиционном приложении я бы взял некоторые данные, такие как имя, дата рождения и т. Д., И поместил бы их в существующий объект;как я понимаю, в концепции ES этот подход неверен, , поэтому я должен выполнять разные события для обновления разных частей совокупного корня? Если так, то как построить REST API? Как справиться с валидацией?

Answer 1

В традиционном приложении я бы взял некоторые данные, такие как имя, дата рождения и т. Д., И поместил их в существующий объект;как я понимаю, в концепции ES этот подход неправильный,

Краткий ответ: этот подход хорош - какие изменения в источнике событий связаны с тем, как вы отслеживаете изменения в вашем сервисе.

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

Answer 2

Как уже ответили, подход пакетного обновления в порядке.

Предлагаю сосредоточиться на коде потребления события. Если все, что у вас есть в вашем ReadSide, является полным агрегатным представлением, тогда общее событие * _UPDATED в порядке.

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

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

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

Answer 3

Этот вопрос действительно слишком широк для SO. Чтобы найти подробные статьи, проекты github, видеоролики и другие ответы на эти вопросы, вам нужно зайти в Google «Основы поиска событий в лазури».

В общем, в Event Sourcing есть две основные идеи, которые вам нужны - сообщения и события. Типичный процесс (не единственный, а общий) выглядит следующим образом. Ваш пользовательский интерфейс создает сообщение, которое делает запрос на изменение в AR. Проверка этого сообщения выполняется на источнике создания сообщения.

Затем сообщение отправляется в API, где оно снова проверяется, поскольку вы не можете доверять всем возможным отправителям. Запрос обрабатывается, в результате чего вносятся изменения в AR. Затем создается событие, описывающее внесенные изменения, и это событие помещается в источник события (концентратор событий Azure, Kafka, Kinesis, БД и т. Д.). Этот список событий сохраняется навсегда и описывает каждое изменение, внесенное в этот AR в течение времени, включая первоначальный запрос на создание. Чтобы получить текущее состояние AR, просто сложите все события.

Ключевая идея, которая вводит в заблуждение при изучении источников событий, - это два разных типа «событий». Сообщения просят о внесении изменений. В «Журнале событий» записывается, что изменение было внесено.