Основы EventStore — в чем разница между метаданными/метаданными событий и данными событий?

Я только начинаю использовать / понимать EventStore или get-event-store, как это может быть известно здесь.

Я изучил документацию по клиентам, прогнозам и подпискам и чувствую, что готов начать использовать ее в некоторых внутренних проектах.

Одна вещь, которую я не могу пройти мимо: есть ли руководство/набор рекомендаций для описания разницы между метаданными событий и данными? Я знаю об условных различиях; Данные о событиях — это «ядро» для домена, метаданные для описания, но они становятся довольно философскими.

Интересно, существуют ли жесткие правила в отношении реализации (запросы и т. д.).

Любое руководство вообще с благодарностью!


metadata eventstoredb
person penderi    schedule 25.08.2015    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Я поделюсь с вами своим опытом, который может помочь. Я играл с akka-persistence, akka-persistence-eventstore и eventstore. akka-persistence хранит свою оболочку событий, PersistentRepr, в двоичном формате. Я хотел, чтобы эти данные были в формате JSON, чтобы я мог:

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

Вы можете реализовать свою собственную сериализацию для akka-persistence-eventstore, чтобы сделать это, но это все равно закончилось просто сохранением оболочки, в которой мое событие было встроено в атрибут полезной нагрузки. Все остальные атрибуты были специфичны для akka-persistence. Автор akka-persistence-eventstore дал мне хороший совет: заставить сериализатор хранить полезную нагрузку как данные, а остальное — как метаданные. Таким образом, мое событие теперь представляет собой просто бизнес-данные, а метаданные помогают технологии, которая изначально их поместила. Моим прогнозам теперь не нужно анализировать метаданные, чтобы получить полезную нагрузку.

person Peter vd Merwe    schedule 04.09.2015

arrow_upward
2
arrow_downward

Бесстыдное копирование (и перефразирование) частей из сообщения в блоге Szymon Kulec "Наполнение ваших мероприятий важными метаданными" (выделено мной):

Но какую информацию может быть полезно хранить в метаданных, какую информацию стоит хранить, несмотря на то, что она не была зафиксирована при создании модели?

1. Данные аудита

  • кто? — просто сохраните идентификатор пользователя инициатора действия.
  • когда? — временная метка действия и события.
  • почему? — сериализованное намерение/действие актера.

2. Управление версиями событий

Источник событий имеет дело с эффектом действий. Действие, выполняемое в состоянии, приводит к действию в соответствии с текущей реализацией. Ждать. Текущая реализация? Да, реализация вашего агрегата может измениться, и это произойдет либо из-за исправления ошибок, либо из-за добавления новых функций. Было бы неплохо, если бы версия, например идентификатор коммита (SHA1 для gitters) или семантическая версия, также могла храниться вместе с событием? Представьте, что вы опубликовали неработающую версию, а ваш бизнес продали. 100 билетов до исправления ошибки. Было бы неплохо иметь возможность указать, какие события были созданы на основе сломанной реализации. Обладая этими знаниями, вы можете легко компенсировать транзакции, совершенные сломанной реализацией.

3. Детали реализации документа

Довольно часто вводятся канареечные релизы, переключение функций и A/B-тесты для пользователей. Благодаря автоматизированному развертыванию и небольшому усовершенствованию кода все упомянутые подходы можно включить в проектную доску. Если вы считаете, что переключатели или разные реализации сосуществуют в один и тот же момент, хранения только версии может быть недостаточно. Как насчет добавления информации о том, какие функции были применены для действия? Просто создайте простой набор включенных функций или сопоставьте статус функции и добавьте его к событию. Имея это и команду, легко повторить процесс. Кроме того, легко проводить эксперименты A/B. Просто запустите сканирование событий с включенным A и другое для событий B.

4. Оптимизированная комбинация 2. и 3.

Если вы считаете, что это слишком много, создайте поиск наборов функций версий x. Он не такой большой и повторяется для многих пользователей, поэтому вы можете легко оптимизировать хранение набора в другом месте под ссылочным ключом. Вы можете сериализовать эту карту и рассчитать SHA1, поместить значения в карту (таблица также подойдет) и использовать идентификаторы, чтобы поместить их в событие. Существует множество вариантов переложить нагрузку либо на запрос (запросы), либо на хранилище (хранить все как именованные метаданные).

Подведение итогов

Если вы создаете архитектуру, основанную на событиях, рассмотрите возможность добавления временного измерения (версии) и небольшой конфигурации в метаданные. Как только вы это сделаете, будет намного проще рассуждать об источниках ваших событий и вводить такие инструменты, как компенсация. Не бывает слишком много данных, не так ли?

person toraritte    schedule 10.01.2019