Хобрук: Ваш путь к мастерству в программировании

DDD: Хранение ссылки на неагрегированный корневой объект из другого ограниченного контекста

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

  • Компания может иметь много Команд.
  • Каждая Команда должна иметь уникальное имя для каждой Компании.
  • Должны быть доступны отчеты для конкретной команды, а также список всех отчетов для компании.

Только что у меня есть 3 ограниченных контекста - компания, команда и отчет. Я считаю, что мне следует переместить команду в компанию, чтобы обеспечить соблюдение моего уникального инварианта имени, однако, насколько я понимаю:

«Ничто за пределами границы агрегата не может содержать ссылку на что-либо внутри, кроме корневой сущности».

Если я могу ссылаться на AR только из своего отчета AR, я не могу сохранить, к какой команде принадлежит мой отчет — только к компании.

Я посчитал, что Команда может существовать как собственная БК, так и в составе БК Компании. В этом случае создание Команды будет происходить только внутри Компании BC как Объекта. Здесь может быть обеспечено присвоение имени и инвариантное применение этого имени команды. В этом случае Team BC по-прежнему будет существовать, и отчет все еще может содержать ссылку на TeamId из отчета AR. Однако это приведет к дублированию TeamId и TeamName как в компании BC, так и в Team BC.

Этот подход звучит нормально, или я что-то упустил?

Я сбит с толку, если у меня есть 3 BC, которые должны быть 2 BC, или отсутствует концепция Team Entity в компании BC.

Может быть, я путаю ограниченные контексты. У меня есть/нужны только совокупные корни - я не уверен!

Гул, помоги!

domain-driven-design aggregateroot bounded-contexts domain-model
16.03.2015

  • Я предлагаю вам прочитать DDD, чтобы разница между BC и Aggregates стала более ясной — сейчас действительно может возникнуть путаница. 18.03.2015
  • @acairns Вы нашли решение своей проблемы? 24.10.2017

Ответы:


1

В вашем примере компания и команда не могут быть ограниченными контекстами, это сущность (компания или команда могут быть корнем агрегации, это зависит от задачи), у компании есть идентификатор имени, у команды есть идентификатор компании + имя_команды.

Ограниченный контекст — это связный набор моделей, который должен отражать смысл выбранного субдомена. Команда и компания могут формировать один BC, отчетность — это другой контекст.

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

16.03.2015
  • Большое спасибо за ваш ответ. Репортаж намного больше, чем моя упрощенная версия, с вопросами и ответами. Если бы я принял ваше предложение и имел один BC, содержащий как Company, так и Team, как бы Report ссылался на команду, если он не может хранить TeamId? Или вы говорите, что Team может быть AR, а Company может быть AR в одном и том же BC? 16.03.2015
  • @acairns Один корень агрегации может содержать другой корень агрегации, например. Компания AR может содержать Team AR, если это необходимо. Но в этом случае вы не можете использовать Team AR вне Company AR в той же БК, потому что вы можете нарушить инвариант Company AR. 17.03.2015
  • @acairns Суть предложения Ничто вне границы Aggregate не может содержать ссылку ни на что внутри, кроме как на корневую Entity в том, что в одной транзакции вы должны выполнять операцию в одном BC, в одном AR. В то время, когда вы выполняете какую-либо операцию или в БК «Компания + Команда», или в БК «Отчетность», если вы не можете этого сделать, то вам следует перепроектировать свои Контексты. Если вы можете работать с BC Reporting, не затрагивая другие BC, то вполне нормально, что Report содержит ссылку TeamId. 17.03.2015
    • Новые материалы
    Создание кнопочного меню с использованием HTML, CSS и JavaScript
    Вы будете создавать кнопочное меню, которое имеет состояние наведения, а также позволяет вам выбирать кнопку при нажатии на нее. Финальный проект можно увидеть в этом Codepen . Шаг 1..
    Внедрите OAuth в свои веб-приложения для повышения безопасности
    OAuth — это широко распространенный стандарт авторизации, который позволяет приложениям получать доступ к ресурсам от имени пользователя, не раскрывая его пароль. Это позволяет пользователям..
    Классы в JavaScript
    class является образцом java Script Object. Конструкция «class» позволяет определять классы на основе прототипов с чистым, красивым синтаксисом. // define class Human class Human {..
    Как свинг-трейдеры могут использовать ИИ для больших выигрышей
    По мере того как все больше и больше профессиональных трейдеров и активных розничных трейдеров узнают о возможностях, которые предоставляет искусственный интеллект и машинное обучение для улучшения..
    Как построить любой стол
    Я разработчик программного обеспечения. Я люблю делать вещи и всегда любил. Для меня программирование всегда было способом создавать вещи, используя только компьютер и мое воображение...
    Обзор: Машинное обучение: классификация
    Только что закончил третий курс курса 4 часть специализации по машинному обучению . Как и второй курс, он был посвящен низкоуровневой работе алгоритмов машинного обучения. Что касается..
    Разработка расширений Qlik Sense с qExt
    Использование современных инструментов веб-разработки для разработки крутых расширений Вы когда-нибудь хотели кнопку для установки переменной в приложении Qlik Sense? Когда-нибудь просили..