Вопрос
Итак, я читал книгу Вона Вернона «Implementing domain-driven design by Vaugh Vernon», и там есть кое-что, чего я не понимаю. Чтобы было понятно, давайте посмотрим на картинку, которую я взял из книги. Вот как он описывает концепции DDD, такие, как Ограниченный контекст, Поддомен и т.д.
Итак, как вы можете видеть на картинке, она описывает Домен розничной компании. У вас есть неявный Ограниченный контекст, а также Поддомен внутри ограниченного контекста, но, прочитав еще несколько страниц, я нашел эту картинку.
Итак, теперь это сбивает меня с толку, потому что на первом изображении Поддомен находится внутри Ограниченного контекста, но на втором изображении Ограниченный контекст вместо этого находится внутри Поддомена (Core, Support, Generic). Итак, что же на самом деле представляет собой Поддомен, который он описывает на первой картинке. Это то же самое, что и на второй картинке?
Ответ
У вас нет Поддоменов внутри Ограниченного контекста. Скорее так:
- Домен отображает Область задач
- Ограниченный Контекст отображает Область решений
В терминах софта это относится к реализации решения для конкретной проблемы.
У каждой компании есть общий домен, который обычно состоит из различных поддоменов, если домен имеет определенную сложность (причина выбора DDD, в конце концов).
Важно отметить, что эти поддомены можно разделить на:
- Основные поддомены (Core Sub-Domain), те, на которых компания зарабатывает деньги, используя свои конкурентные преимущества
- Вспомогательные поддомены (Supporting Sub-Domain), которые на самом деле не добавляют ценности для конечного клиента, но необходимы для реализации работы основных поддоменов, а также представляют собой довольно специфические проблемы компании, которые не могут быть решены с помощью готовых реализаций на рынке
- Общие поддомены (Generic Sub-Domain), проблемы, характерные для нескольких компаний
Например, у цветочного интернет-магазина основной поддомен - супербыстрая доставка цветов в тот же день.
Тогда, например, их закупки могут быть вспомогательным доменом - не имеющим отношения к конечному клиенту, но достаточно сложным и индивидуальным, чтобы проблемы этого домена не были похожи на проблемы других компаний.
А то, как они обеспечивают авторизацию на сайте для клиентов (например, с помощью OpenID Connect / OAuth2), будет общим поддоменом, для которого они предпочтут использовать готовое решение и не будут внедрять собственного провайдера идентификации.
Соответствующие ограниченные контексты - это просто соответствующие решения этих проблем (поддомены). Хотя между поддоменами и ограниченными контекстами может существовать отображение 1:1, это не обязательно так.
В то время как поддомены обнаруживаются, ограниченные контексты разрабатываются и моделируются, чтобы обеспечить наилучшее решение проблемного пространства и определить соответствующие границы, которые имеют смысл в вашей системе.
Как разработчики мы не можем выбирать, какие поддомены существуют, это само собой разумеется. Но мы можем, с учетом контекста и ограничений ситуации, выбрать, как мы разделим границы, например, физическое разделение или разделение ответственности за командную разработку. В любом случае мы должны знать, что ограниченный контекст определяет границы языка, и мы должны быть уверены, что в языке нет конфликтов внутри этого ограниченного контекста.
Обновление
Я хочу ответить на дополнительный вопрос (см. комментарий):
Может ли ограниченный контекст жить более чем в одном поддомене? Как видно на втором рисунке, ограниченный контекст внутри общего поддомена, похоже, пересекается с другими поддоменами.
Я рекомендую взглянуть на рисунок 2.4 и соответствующий текст в книге, в главе 2, REAL-WORLD DOMAINS AND SUBDOMAINS.
В данном случае общим поддоменом является ERP (планирование ресурсов предприятия). Это хороший пример того, что доступно в виде программного обеспечения от сторонних поставщиков и может быть интегрировано в вашу систему.
Соответствующий ограниченный контекст ERP перекрывает поддомены инвентаризации и закупок, поскольку эта реализация также предоставляет модули ERP инвентаризации и закупок (или API), которые позволяют этим поддоменам использовать контекст ERP.
Таким образом, хотя эти специфические модули (или API) удовлетворяют потребности вспомогательных поддоменов инвентаризации и закупок, они реализованы в ограниченном контексте ERP, а не в ограниченных контекстах инвентаризации и закупок.
Так что да, хотя отображение 1:1 между поддоменами и ограниченными контекстами было бы желательным, когда дело доходит до реализации, иногда бывает необходимо, чтобы один ограниченный контекст работал с требованиями из более чем одного поддомена.
Кроме того, в legacy системах часто существуют ограничения, которые не позволяют свободно создавать оптимальный дизайн ограниченных контекстов.