DDD ограниченные контексты и домены?

16

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

Я взял книгу « Внедрение DDD», и первое, что он упомянул, это «DDD-Lite» и «Ограниченные контексты и доменные события», пропущенные как первые ошибки, которые обычно возникают при начале DDD.

В настоящее время я пытался организовать модель предметной области по совокупности и использовать пространства имен для ее демонстрации.

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

лько
источник
Мне кажется, что единственное, что определяет отдельные ограниченные контексты, - это необходимость различать лингвистику и связанные с ней операционные различия, то есть она называется продуктом в одной области и продуктом в другой области, но они разные, поэтому нам нужны два продукта, и они оба могут ' быть в той же модели (то же имя и т. д.). Так почему бы нам просто не изменить имена, чтобы представить их слегка различную семантику? Они могут иметь одну модель, чтобы управлять ими всеми. Субдомены естественны, но я не вижу ограниченного контекста в данный момент. Просто мысли вслух здесь ...
Эшли Айткен
Я думаю, вы уже поняли, почему выгодно разделять ваш домен по контекстам. Так что сейчас может пригодиться правильный способ их идентификации, определения границ контекста. Вот как я это делаю: medium.com/@wrong.about/...
Zapadlo

Ответы:

20

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

  • Разработка программного обеспечения
  • HR
  • Учет

Можете ли вы придумать модель пользователя, которая может выразительно представить все эти сферы бизнеса? Подумайте, как может выглядеть сущность User в каждом из них. Возможно, он разделен на три разных объекта:

  • разработчик
  • Сотрудник
  • векселедержатель

Усилия по созданию экземпляра пользователя в каждом контексте значительно различаются. Возможно, это что-то вроде этого:

  • новый сотрудник (ссн, имя, фамилия, дата рождения, пол)
  • новый разработчик (сотрудник, рабочая станция, учетные данные)
  • новый получатель (сотрудник, роль)

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

Если бы вы использовали наивную реализацию и использовали один пользовательский объект, то в конечном итоге это была бы анемичная модель данных, полная геттеров и сеттеров, потому что вы не могли полностью представить пользователя повсюду.

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

Думая по-другому - теперь вы можете создать свой код управления разработчиком, который будет очень легковесным и независимым от остальной части вашей системы. Он может использовать более точные типы с меньшим количеством багажа для беспокойства. Это шаг к созданию небольших подсистем, которые в конечном итоге могут быть извлечены в его собственное приложение.

Адриан Шнайдер
источник
Спасибо за вспомогательный пример, который помогает проиллюстрировать различные потребности 3 до н.э.
13
Не так , как я привык видеть эти понятия: Обычно, Employeeэто не User, он имеетUser . Это Userпросто объект, через который человек может войти в систему и получить доступ к одному или нескольким приложениям внутри организации. И Employeeне всегда есть User. Кроме того, вы обычно не получаете простое приложение для разных отделов; как правило, у каждого отдела есть свои собственные приложения, каждое из которых содержит свою собственную модель (ы) домена. Таким образом, мне этот ответ не помогает прояснить необходимость иметь отдельные ограниченные контексты в одной и той же кодовой базе.
Роджер
@ Rogério Ваше возражение на самом деле является прекрасным примером того, почему важно правильно определить вездесущие языки, используемые в каждом ограниченном контексте :)
MauganRa
Мне просто интересно в тех случаях, когда у нас есть система управления клиентами, когда мы звоним по телефону, чтобы запросить наши заказы, или выставление счетов и т. Д., Мы задерживаемся, пока нас переводят в соответствующий отдел. Знание предметной области каждого отдела вступает в игру - очень к раздражению клиента в этих сценариях. Может быть, мы можем обвинить DDD в навязывании разделения между этими контекстами.
Андес
16

Я могу привести еще один пример. Предположим, у вас есть система электронной коммерции. У вас будут продукты, но продукты будут входить как минимум в два разных домена:

  • Каталог товаров, где вы храните описание товара и все атрибуты
  • Инвентаризация, где у вас есть запас товара

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

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

Обновление: на SkillsMatter есть хорошая квалификация от Эрика Эванса. Он приводит аналогию со старой историей, когда несколько слепых описывают слона с их точки зрения. Поскольку каждый человек может коснуться только части слона, они описывают его как «дерево», «стена», «змея», «веревка». И каждый из этих людей прав в своем контексте. Ограниченный контекст - это место, где живет вездесущий язык. Вне контекста эти термины могут иметь совершенно другое значение, но внутри контекста язык одинаков для разных доменов. Грег Янг настоятельно рекомендует начать чтение синей книги из главы 11, поскольку там объясняются наиболее важные фундаментальные понятия. Сосредоточение внимания на тактических схемах в начале книги делает этот подход «DDD-light» очень распространенным,

Алексей Зимарев
источник
1
+1 за то, что тоже поднял дубликат. сначала это немного сбивает с толку («Я что-то не так делаю ?!), но это совершенно естественно, во многих случаях требуется.
Адриан Шнайдер
В этом сценарии Productоба эти класса гипотетически совместно используют один и тот же идентификатор (например, обе отдельные таблицы BC имеют внешний ключ к таблице с одним идентификатором продукта)? Возможно, при общении с Domain Events они могли использовать этот идентификатор?
13:05
1
Все зависит от того, какое хранилище выбрано. Нет необходимости использовать технический идентификатор для ссылки на междоменный домен. Также не рекомендуется делать кросс-контекстную коммуникацию.
Алексей Зимарев
1
Похоже, пришло время вынуть синюю книгу с полки и прочитать эти более поздние главы
Маркус Пшеидт