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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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