DDD: вложенные агрегаты и многие из многих отношений

Question

В настоящее время я работаю над ограниченным публикацией контекстом. Основными игроками в этом контексте являются Продукт и Список.

Продукт: может быть указан на нескольких торговых площадках. Один Продукт Много Listing.

Листинг: может быть много продуктов, потому что некоторые варианты вариантов поддержки на рынке. Один Список Много Продукт.

На основании вышеизложенного у меня есть многие-ко-многим между листинга и продукт.

Я создал агрегат для обоих. Агрегат продукта, который содержит списки и агрегирование листинга, которое содержит продукты.

Допустимо ли иметь Листинг, определенный в обоих агрегатах, или я должен определить листинг один раз для использования в обоих агрегатах?

Первый Листинг будет в совокупности продукта, поскольку AR продукт имеет фабричный метод, который применяет правила при создании листинга (например, во избежание дублирования листинга на одном рынке и гарантировать, что мы имеем наличии Кол-во для листинга)

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

У двух агрегатов слишком много перекрытий с дублирующими определениями? Можно ли ожидать этого в одном ограниченном контексте?

Также как сохранить дублирующее представление листинга синхронизировать друг с другом?

Answer 1

первый список будет находиться в пределах совокупности продукта, поскольку AR продукт имеет фабричный метод, который применяет правила при создании листинга (например, во избежание дублирования листинга на одном рынке и гарантировать, что мы имеем наличии Кол-во для листинга)

Должен ли продукт знать свой собственный запас, собственные рынки, собственные списки и создавать списки тоже? Это слишком большая ответственность за сущность! Я бы предложил, чтобы ListFactory проверил акции и рыночные показатели с другими службами или репозиториями, которые хранят эту информацию.

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

Избегайте циклическую зависимость между продуктом и листингом и беспорядком, поддерживая единый список (посмотреть на этот вопрос для подобной путаницы: How to design many-to-many relationships on deletion?). Кажется, у вас должен быть свод рыночных площадок, в котором содержатся ваши списки. Вы можете настроить сервисный центр или репозиторий на рынке, который получает все листинги, если вам нужно получить доступ ко всем спискам на основе продукта (например, в списке, представленном в ListFactory, который я предложил).

У двух агрегатов слишком много перекрытий с дублирующими определениями?

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

Можно ли ожидать этого в пределах одного ограниченного контекста?

Все определения подкрепляют друг друга, так что в любом контексте, вы можете ожидать, дублирования, синонимов, расширений, недалеко от подобия, перекрестных ссылок, различные типы отношений и т.д. Это требует совсем немного следственного сознания отделить первичный от вторичного, предикаты от предметов и объектов, ядро ​​от мембраны. Тем не менее, это также то, что делает это так весело :)

определения слова: «Единый отчетливый значимый элемент речи или писем, используемый с другими (или иногда только), чтобы сформировать предложение ..»

определение предложения: «множество слов, является полным само по себе, как правило, содержащие подлежащее и сказуемое, передавая заявление, вопрос, восклицание ..»