Перестроить запросы из событий домена несколькими агрегатами

Question

Я использую подход DDD/CQRS/ES, и у меня есть некоторые вопросы о моделировании моих агрегатов и запросов. В качестве примера рассмотрим следующий сценарий:

Пользователь может создать WorkItem, изменить его заголовок и связать с ним других пользователей. В WorkItem есть участники (ассоциированные пользователи), и участник может добавлять Actions в WorkItem. Участники могут выполнять действия.

Предположим, что пользователи уже созданы, и мне нужны только пользовательские идентификаторы.

У меня есть следующие WorkItem команды:

• CreateWorkItem
• ChangeTitle
• AddParticipant
• AddAction
• ExecuteAction

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

И следующий запрос:

• WorkItemDetails (вся информация для рабочего элемента)

Запросов обновляются обработчиками, которые обрабатывают событие домена, поднятое WorkItem агрегат (ов) (после того, как они» повторно сохранены в EventStore). Все эти события содержат WorkItemId. Я хотел бы иметь возможность перестраивать запросы «на лету» при необходимости, загружая все соответствующие события и обрабатывая их последовательно. Это связано с тем, что мои пользователи обычно не получают доступ к WorkItems, созданным год назад, поэтому мне не нужно обрабатывать эти запросы. Поэтому, когда я получаю запрос, которого не существует, я мог бы его перестроить и сохранить в хранилище ключей/значений с помощью TTL.

События домена имеют aggregateId (используется как поток потока событий и ключ осколка) и sequenceId (используется как eventId в потоке событий).

Итак, моя первая попытка состояла в создании большого агрегата под названием WorkItem, в котором собрана коллекция участников и коллекция действий. Участники и действия - это объекты, которые живут только внутри WorkItem. Участник ссылается на userId, и действие ссылается на участникId. Они могут иметь больше информации, но это не относится к этому упражнению. С помощью этого решения мой большой агрегат WorkItem может гарантировать, что команды являются идемпотентными, потому что я могу проверить, что я не добавляю повторяющихся участников или действия, и если я хочу перестроить запрос WorkItemDetails, я просто загружаю/обрабатываю все события для данного WorkItemID.

Это работает отлично, потому что, поскольку у меня есть только один агрегат, WorkItemId может быть aggregateId, поэтому, когда я перестраиваю запрос, я просто загружаю все события для данного WorkItemId. Однако это решение имеет проблемы с производительностью большого агрегата (зачем загружать всех участников и действия для обработки команды ChangeTitle?).

Итак, моя следующая попытка состоит в том, чтобы иметь разные агрегаты, все с одним и тем же WorkItemId как свойство, но только агрегат WorkItem имеет его как aggregateId. Это устраняет проблемы с производительностью, я могу обновить запрос, потому что все события содержат WorkItemId, но теперь моя проблема в том, что я не могу его перестроить с нуля, потому что я не знаю агрегированные данные для других агрегатов, поэтому я не могу загрузить их потоки событий и обрабатывать их.У них есть свойство WorkItemId, но это не их реальный aggregateId. Также я не могу гарантировать, что я обрабатываю события последовательно, потому что у каждого агрегата будет свой собственный поток событий, но я не уверен, что это настоящая проблема.

Другим решением, о котором я могу думать, является создание выделенного потока событий для консолидации всех событий WorkItem, создаваемых несколькими агрегатами. Поэтому у меня могут быть обработчики событий, которые просто добавляют события, инициированные Участником, и Действия к потоку событий, идентификатор которого будет похож на «{workItemId}: allevents». Это будет использоваться только для восстановления запроса WorkItemDetails. Это звучит как хак. В основном я создаю «совокупность», которая не имеет бизнес-операций.

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

Любая помощь по этому поводу очень ценится.

Благодаря

Answer 1

Я не думаю, что вы должны разработать свои агрегаты с запрашивая проблемами в виду. Сторона «Чтение» предназначена для этого.

На стороне домена сосредоточиться на проблемах согласованности (насколько мала может быть совокупность, а домен по-прежнему остается согласованным в одной транзакции), параллелизм (насколько он может быть и не страдать от одновременных проблем доступа/условий гонки)? и производительность (будем ли мы загружать тысячи объектов в памяти только для выполнения простой команды?) именно то, что вы просили).

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

Если вы идете несколько малых агрегаты маршрута и ваш Read модель нуждается в информации из нескольких источников, чтобы обновить себя, у вас есть несколько вариантов:

• Пополните излучаемое событие с дополнительными данными

• Чтение из нескольких потоков событий и объединение их данных для построения модели чтения. Никакая магия здесь, сторона Read должна знать, какие агрегаты участвуют в определенной проекции. Вы также можете запросить другие прочитанные модели, если знаете, что они актуальны и предоставят вам только нужные вам данные.

См CQRS events do not contain details needed for updating read model