DDD - Как управлять объектами в ограниченном контексте в EF Core

Question

Я не нашел конкретных примеров этого. Я знаю, что у каждого ограниченного контекста есть свои версии сущностей, и вы не должны делиться сущностями в разных контекстах. Но как мне управлять этим в связи с использованием ORM, такого как EF?

Например, ниже приведены мои сущности и ограниченные контексты, в которых они существуют:

Ingredient (контекст, ограниченный сущностью A)

Рецепт (контекст, ограниченный сущностью b)
Ингредиент (контекст, ограниченный сущностью b)
MenuItem (совокупный ограниченный контекст b)

Теперь каждый ограниченный контекст будет иметь свою собственную версию ингредиента. Но так как у меня есть особый контекст БД в EF для управления этим, как именно это организовать? Я использую CQRS, чтобы при необходимости вызывать события. Мой план состоял в том, чтобы поддерживать список идентификаторов в моей сущности Recipe и извлекать соответствующие ингредиенты из базы данных, чтобы данные не дублировались.

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

В одном контексте ингредиенты не имеют отношения к другой сущности, в то время как в другом контексте это дочерняя сущность (в совокупности). Я могу видеть, как это должно быть разработано (отдельные объекты в ограниченном контексте), но когда дело доходит до БД, как это на самом деле происходит? Что, если знание свойств / предметной области, которые необходимо отслеживать в контексте A по сравнению с контекстом B для ингредиентов, отличается? Будет ли это в конечном итоге отдельной таблицей? Я немного запутался в этом.

Редактировать: Пожалуйста, имейте в виду, что я использую только 1 базу данных здесь. Я понимаю, что обычно у вас есть отдельная БД на ограниченный контекст, чтобы избежать этого сценария, но мне было интересно, как это можно сделать с помощью 1 БД.

Answer 1

Я бы разделил ваш вопрос на две части:

1. Архитектурная часть: ограниченный контекстный дизайн / границы
2. Технологическая часть: управление схемой базы данных, отображение EF и т. Д. c

С точки зрения 1 я бы подчеркнул, что границы ограниченного контекста толще, чем то, что вы подразумеваете в своем вопросе. Если границы четко определены, существует небольшое дублирование данных между BC, часть из некоторых идентификаторов и немного больше. В вашем случае ингредиенты в B C -A имеют те же идентификаторы, что и ингредиенты в B C -B.

Например, ваш B C -A может управлять именем, описанием, фотографиями и т. Д. Из ингредиентов. B C -B не нуждается в этой информации, но вместо этого может иметь некоторые важные свойства, необходимые для создания рецептов. Аналогичным образом, B C - C может иметь поставщиков, цены и так далее каждого ингредиента.

Кроме того, в вашем B C -B ингредиенты могут находиться в двух местах: в таблице со всеми ингредиентами и их интересными свойствами для рецептов, а также в качестве сущностей в составе рецепта. У этой сущности не было бы всех этих свойств, вместо этого у нее был бы Идентификатор ингредиента плюс количество, использованное в этом рецепте, например.

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

Во многих случаях необходимость дублирования данных исходит из потребностей пользовательского интерфейса. Например, вам нужно будет показывать имена ингредиентов, когда вы показываете рецепты, но это можно решить с помощью композиции пользовательского интерфейса. Пользовательский интерфейс может получить рецепты из B C -B и обогатить данные названиями из B C -A и, возможно, ценами из B C - C.

Если вы следуете этому подходу, точка 2 должна быть самостоятельной: каждый B C должен иметь свой собственный DbContext. Можно использовать одну и ту же строку подключения (базу данных) для всего DbContext, но вы можете инициализировать DbContext с указанием схемы c DB. Таким образом, вы можете иметь таблицу Ingredients в каждом B C без конфликтов таблиц DB, и вы можете иметь таблицы версий миграции EF для DbContext (хотя я считаю, что это также работает с общей таблицей). Эта настройка также дает вам преимущество, заключающееся в том, что вы можете разделять базы данных в одной БД для ограниченного контекста без необходимости изменения какого-либо кода. Это может понадобиться в конечном итоге по соображениям масштабируемости или для упрощения инфраструктуры в виде кода и т. Д. c.

Answer 2

TL / DR: наличие единой службы дБ - это нормально (для небольших услуг или по какой-то причине, определенной по факту c), , если данные не передаются . Если вы используете обычную форму db, используйте разные таблицы для хранения ваших двух ингредиентов.

Более длинная версия:

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

Один очень важный аспект наличия B C в качестве границы, чтобы точно позволить этим сущностям развиваться независимо. Имея общую таблицу (или коллекцию документов), вы не допускаете, чтобы это произошло. Более того, это нарушает более общий c (я имею в виду не DDD конкретный c) принцип "вы не должны совместно использовать БД через границы служб".