Я получил ряд комментариев по моему предложению о ленивом поиске событий / базе данных источников событий, как лично, так и в Интернете. Самые громкие из них — это те, кто утверждает, что это не источник событий. К сожалению, довольно часто не могу получить более развернутый ответ. Легче объяснить ход мыслей, который лег в основу текущей реализации Eventsourcing. Но я не могу встретиться со всеми, поэтому я попытаюсь объяснить это здесь.

Прежде всего, я хочу показать, что вы можете использовать его для реализации того, что мы можем назвать «классической» моделью поиска событий (которая часто дополняется DDD и CQRS), из-за отсутствия лучшего отличительного термина. Вот некоторые из критериев, которые я использую для идентификации этой модели (это не исчерпывающий список, и не все из них должны быть верными, поэтому этот набор определенно немного расплывчатый):

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

Несмотря на то, что модель ленивых источников событий ориентирована на позднюю привязку домена, вы все равно можете предпринимать упреждающие действия по каждой журналируемой команде. Вот для чего нужны подписчики юридических лиц. Их можно использовать для фильтрации интересующих нас событий, пока команда все еще обрабатывается, и для получения их потока после того, как они были занесены в журнал. Способ ведения журнала заключается в том, что никакое событие не считается занесенным в журнал, если все другие события, созданные командой, также не были успешно занесены в журнал, что делает каждую команду областью транзакции.

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

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

Ранее я упоминал менеджеров процессов. В этой модели диспетчер процессов — это просто еще один подписчик, который организует процесс привязки/бизнес-логики при получении определенного типа события.

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

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

Одним из аргументов против было то, что он на самом деле не использует принципы DDD для проектирования четко разделенных контекстов. На что я отвечаю (и спасибо кому-то на Polyglot Conference в Ванкувере за термин!) что мы просто делаем позднее связывание с доменом — не когда изменения записываются, а когда запрашиваются элементы домена. Непосредственным преимуществом этого является то, что мы можем одновременно иметь несколько, даже частично перекрывающихся доменов, в зависимости от того, как мы смотрим на проблему. Это также позволяет улучшать домены, поскольку мы относительно безболезненно получаем больше знаний (нет глобальной схемы для миграции). Этот подход имеет некоторые потенциальные недостатки. Например, использование четко разработанного вездесущего языка для каждой области определенно труднее достичь, поскольку мы развиваем наше понимание предметных областей и используемого языка с течением времени. Тем не менее, это помогает отслеживать эволюцию доменов без необходимости заранее проектировать все это (что в любом случае невозможно в реальном мире).

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

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

Если у вас есть еще аргументы с той или иной стороны, пожалуйста, оставьте комментарий! Я хочу иметь возможность обращаться к ним должным образом.

Моя цель — сделать Eventsourcing еще более подходящим для практиков классической модели. Наша политика вклада в проект — C4, которая по сути гарантирует право на вклад без препятствий оценочного суждения. Если вы чувствуете, что чего-то не хватает, пожалуйста, внесите свой вклад, код и отчеты о проблемах ценны!