Event Sourcing - Совокупное моделирование

Question

Два вопроса 1) Как модель совокупности и ссылка между ними 2) Как организовать/хранить события, так что они могут быть получены эффективно

Возьмите этот типичный случай использования в качестве примера, мы имеют Order и LineItem (они представляют собой совокупность, Order - это совокупный корень) и агрегат продукта. Поскольку LineItem должен знать, какой продукт, так что есть два варианта: 1) LineItem имеет прямую ссылку на агрегат продукта (что кажется не лучшей практикой, поскольку это нарушает идею агрегата, являющегося границей консистенции, потому что мы можем обновлять агрегат продукта непосредственно из Агрегат заказа) 2), тогда LineItem имеет только ProductId.

Похоже, что второй вариант - это путь ... Как вы думаете, что здесь?

Однако возникает другая проблема, связанная с построением модели чтения/просмотра заказа. В этой модели представления заказа он должен знать, какие продукты находятся в заказе (то есть ProductId, Type и т. Д.). Типичным примером использования является отчет, и CommandHandler также может использовать этот объект Product для выполнения логики, например, существует ли слишком много определенных продуктов и т. Д. Чтобы это сделать, учитывая тот факт, что эти данные находятся в двух отдельных агрегатах, тогда мы нужны 1+ обмены базами данных. Поскольку мы используем события для построения модели, поэтому псевдокод выглядит ниже 1) для данного идентификатора заказа (guid, идентификатор агрегата заказа) мы загружаем все события для него; - 1-й доступ к базе данных 2) затем создайте агрегат заказа, затем мы знаем, к какому ProductId относятся в Order; 3) для списка ProductIds мы загружаем для него все события; - 2-й доступ к базе данных

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

Благодаря

Answer 1

Возьмите это типичный случай использования в качестве примера, мы имеем заказ и LINEITEM (они представляют собой совокупность, Орден представляет собой совокупность корень), и продукт агрегата.

Агрегат заказов имеет смысл, как вы его описали. «Агрегат продукта» более подозрительный; вы спрашиваете модель, разрешено ли продукту изменять или вы говорите модели, что продукт изменился?

Если продукт может измениться без предварительной консультации с заказом, тогда LineItem должен не. Ссылка на продукт (он же ProductId) одобрен.

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

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

Когда клиент запрашивает отчет, вы даете им один из кеша. Вся работа выполнена, так что это очень быстро.

Для обработчиков команд ответ более сложный. Бизнес-правила должны быть в модели домена, поэтому наличие обработчика команд для проверки команды (в отличие от модели домена) немного нарушается.

Обработчик команд может загружать продукты, чтобы посмотреть, как может выглядеть это состояние, и передать эту информацию в агрегат с данными команды, но неясно, что это хорошая идея - если клиент отправит команду, которую нужно запустить, и вам необходимо настроить команду «Заказ» с данными «Продукт», почему бы не вместо этого добавить команду данных продукта непосредственно в команду и пропустить среднего человека.

CommandHandler также может использовать этот объект Product, чтобы выполнить логику, например, есть ли слишком много конкретных продуктов и т.д.

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

Для инвентаря реального мира - физическая книга на складе - это, вероятно, неправильный подход. Во-первых, сама модель ошибочна; если вы хотите знать, сколько товаров находится на складе, вы должны запрашивать склад, а не продукт. Во-вторых, физический склад не ограничивается вашей моделью - вызов метода addProduct в агрегировании хранилища не приводит к тому, что продукт волшебным образом появляется там.

В-третьих, это, вероятно, не очень хорошо согласуется с тем, что хотят ваши специалисты по домену. Если модель говорит, что склад не имеет достаточное количество продукта, как вы думаете, владельцы колов, чтобы система

1. сказать покупателю купить продукт где-то еще, или ...
2. принять заказ , и обратитесь к поставщику за новой доставкой.

Подсказка: если у вас возникли сомнения, внимательно просмотрите, как это делает amazon.com.