Event Sourcing с использованием NHibernate

Question

Я перехожу от чистой парадигмы DDD к CQRS. Моя текущая проблема связана с Event Sourcing и, в частности, с организацией Event Store. Я прочитал тонны постов в блогах, но все еще не могу понять некоторые вещи. Так что поправьте меня, если я ошибаюсь.

Каждое событие в основном состоит из: - Дата / время события - тип события (из этого мы также можем определить тип AggregateRoot) - AggregateRoot id (Guid) - версия AggregateRoot (для поддержания порядка обновлений) - Данные о событиях (некоторый сериализованный класс с данными, необходимыми для обновления)

Теперь, если мои данные Event состоят из простых типов значений (целые числа, строки, перечисления и т. Д.), Тогда это легко. Но что, если я должен передать другой AggregateRoot? Я не могу сериализовать весь AR как часть данных событий (подумайте обо всех данных и отложенной загрузке), в основном мне нужно только хранить Id этого AR. Но затем, когда мне нужно применить это событие, мне нужно сначала получить этот AR из базы данных. И это неправильно из моей доменной модели (вызов репозиториев и работа с идентификаторами AR).

Какой лучший подход для этого?

p.s. Для конкретного примера, давайте предположим, что есть Модель, которая состоит из сущностей Task и User (оба AR). Задача провести ссылку на ответственного пользователя. Но ответственный пользователь может быть изменен.

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

Answer 1

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

Например, используя обычную проблему Order / LineItem и Product, мы скопировали бы идентификатор продукта и цену в LineItem вместо полной ссылки. Этот способ предотвращает изменение цены Продукта на инварианты агрегата Order / LineItem. Если необходимо обновить цену LineItem после изменения цены Продукта, нам необходимо отследить событие PriceChanged от использованных Продуктов и отправить компенсационную команду в Order / LineItem. Обычно эта координация / синхронизация обрабатывается сагой.

Answer 2

Как я понимаю Event Sourcing, он должен помочь людям избавиться от реляционных моделей данных и ORM, таких как NHibernate или Entity Framework, поскольку каждая из них является наукой сама по себе.Программисты могли бы тогда просто сосредоточиться на бизнес-логике.Я видел здесь некоторые реляционные схемы, используемые для хранилищ событий, и они представляли собой просто ID, Version, Timestamp плюс столбец NClob или NVarchar (max) для хранения полезной нагрузки события без схемы.

Answer 3

В Event Sourcing состояние агрегата определяется событиями, и ничего более. Все, что связано с моделью предметной области (аля DDD), предназначено только для того, чтобы решить, какие события домена следует инициировать. Событие не должно ничего знать о вашем Домене, это должен быть простой DTO. На самом деле, вполне нормально иметь Event Sourcing без DDD.