CQRS - разрешенные зависимости для построения модели чтения с использованием событий и других источников информации

Question

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

Конкретное событие содержит информацию об изменениях, сделанных в модели предметной области. Я думаю, что в некоторых случаях этой информации недостаточно для построения представления - то есть неизмененные поля, неизмененные объекты отсутствуют в таком событии и т. Д.

Итак, мой вопрос:

Допускается ли, чтобы денормализатор, отвечающий за построение модели чтения, обращался не только к событиям, но также:

1. измененная сущность, на которую ссылаются напрямую в случае?
2. изменен агрегированный корень и любой юридическое лицо, связанное с этой совокупностью?
3. какая-либо сущность извлечена из хранилища?
4. любой вид?

Что вы думаете о допустимых зависимостях для обработчиков событий (денормализаторов)?

edit: Только что добавил простой пример к вопросу выше:

Предположим, следующая модель:

AR: ProductOffering * название * описание * категория * цена

AR: Клиент * название * тип * Метод: покупка продукта (productOffering), который испускает Событие ProductPurchasedByCustomer

сущность: ProductInstance * покупатель * productOffering

событие: ProductPurchasedByCustomer * Пользовательский ИД * productOfferingId

просмотр: ProductInventoryView * Пользовательский ИД * productOfferingId * Тип клиента * productOfferingName * productOfferingCategory * цена

Как построить ProductInventoryView, используя только событие ProductPurchasedByCustomer? Как я могу написать денормализатор для отображения информации о customerType, productOfferingName и т. Д.? Должен ли я искать дополнительную информацию о customerType и productOfferingName из разных представлений?

Answer 1

Если для потребителя события требуется больше информации, то он может предоставить необходимую информацию, даже если она не изменилась.Eventorscing не следует рассматривать как ORM.Имейте в виду, что в отношении того, как вы получаете эту информацию, может быть сложно, но давайте не будем усложнять ситуацию (пока)Обработчики событий могут использовать состояние (данные) модели чтения, если оно не предоставлено событием.Но для этого необходимо знать, какие данные вы можете использовать.Это требует, чтобы вы связали время с данными.Сообщения / события могут быть обработаны не по порядку.Таким образом, предоставить информацию о событии, относящуюся к событию, гораздо проще.Попробуйте сделать это, прежде чем делать что-либо еще.Не пытайтесь получить доступ к вашему домену из обработчиков событий, специфичных для вашей модели чтения, это просто неприятная связь.И последнее: агрегаты могут копировать данные из других агрегатов для предоставления данных, которые вам нужны в ваших событиях.Помните, что с этого момента вам придется задуматься о том, как сохранить эти данные свежими в агрегатах, которые их сначала скопировали.Возможно, вас смутило еще немного ...

Answer 2

Насколько я понимаю:

изменена сущность, на которую непосредственно ссылается событие?

нет

изменилась совокупная корень и любая сущность, связаннаяв этот агрегат?

нет

какая-либо сущность, выбранная из домена хранилище?

нет

любой отчет, который не связан с событием

нет

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

да

изменен агрегатный корень отчет и любая сущность отчет , относящаяся к агрегату, указанному в событии?

да

---

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

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