Domain-Driven Design — это, как правило, подход к проектированию систем программного обеспечения, который предполагает создание общего языка между экспертами домена и разработчиками системы. В число известных правил DDD входят Use a Ubiquitous Language и Make The Implicit Explicit.

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

Данная статья подготовлена в результате длительной беседы на github с участием многих представителей сообщества DDD. Спасибо всем участникам этого диалога за сотрудничество.

Неявно, но не двусмысленн

Прежде чем дать определение каждому термину, я хочу отметить важную мысль, которую высказывает Kenny Baas-Schwegler. Он утверждает, что DDD должен быть неявным. Благодаря неявности DDD мы можем исследовать, моделировать и решать все новые и новые проблемы, потому что существующие шаблоны и принципы не ограничивают наше мышление.

Под неявностью я подразумеваю, что слово можно использовать для описания различных вещей, которые в чем-то похожи, но не идентичны. Хорошим примером является слово "немного". В некоторых вариантах оно может означать небольшой диапазон, например 2-3, а в иных может означать другой диапазон, например 5-10. В прочих случаях оно может означать 100 фунтов стерлингов: "Не могли бы вы одолжить мне несколько фунтов?". Главное, чтобы неявность хорошо выводилась из контекста (если разные люди интерпретируют его существенно по-разному, это слишком двусмысленно).

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

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

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

Домены

Domain-Driven Design тесно связан с определением домена в Кембриджском словаре:

область  интересов или область, над которой человек имеет контроль:

Она относилась к бизнесу как к своему частной собственности (domain).

Данные документы находятся в общественном достоянии (domain) (= доступны всем)

Такое определение домена очень расплывчато. Что такое область интересов? Это может быть что угодно. Домен — это фактически произвольная граница среди других существующих концепций.

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

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

Мы можем сгруппировать квадратные фигуры в домен Squares, а круги — в домен Circles. Однако синий квадрат и синий круг также могут принадлежать домену Blue.

При моделировании систем мы должны выбрать наиболее подходящие границы домена, с которыми мы будем согласовывать наше программное обеспечение и организационные ограничения. Даже если мы выбираем соответствие по "цвету", домен формы все равно останется.

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

Поддомены

В чем разница между доменом и поддоменом? Здесь все просто — поддомен не является словом, которое существует в словаре. Слово поддомен широко используется в мире веб-хостинга, но что оно означает в DDD?

В DDD поддомен — это относительное понятие. Домен и поддомен могут использоваться как взаимозаменяемые термины. Когда мы используем слово поддомен, то подчеркиваем, что домен, о котором говорится, является дочерним по отношению к другому домену более высокого уровня, который мы идентифицировали.

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

Основные, общие, вспомогательные (под)домены

Люди часто путаются, когда слышат, что основной домен на самом деле является поддоменом. В своих книгах по DDD Eric Evans называет их основными доменами, но он также называет их поддоменами. Запутались еще больше?

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

Core Domain (основной домен) звучит лучше, Core Subdomain (основной поддомен) подчеркивает, что существует домен более высокого уровня, куда входит данный объект.

Пространство задач в сравнении с пространством решений: лучшая модель для DDD

Самыми запутанными терминами являются пространство задач и пространство решений. У каждого существует свой взгляд на то, что находится в пространстве задач и в пространстве решений согласно контексту Domain-Driven Design.

Я думаю, что модель пространства задач/решений слишком упрощенная для того, что пытается выразить DDD. Она чересчур неоднозначна и требует большей точности. На мой взгляд, элементы цикла стратегии Simon Wardley гораздо больше подходят для использования.

В цикле стратегии Wardley есть следующие элементы (с моими упрощенными определениями):

• Цель: какова проблема, которую мы решаем / цель, которая должна быть достигнута в интересующем нас домене? 

• Среда: каково текущее состояние интересующей нас области (областей).

• Климат: что влияет на интересующую нас область и как это может эволюционировать.

• Доктрина: мы должны применять хорошие универсальные методы.

• Лидерство: каково наше решение... какие изменения мы собираемся внести в существующую и новую область (области).

Являются ли домены/поддомены пространством задач или решений?

На этот вопрос не получится ответить, пока у нас нет четкого определения пространства задач или пространства решений. Но я все равно попробую.

Вы действительно знаете, что такое пространство задач и поддомен, или вы просто слышали их название?

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

Как может поддомен существовать только в пространстве задач, если дизайн определяет, в каких поддоменах нужно строить решения? Следовательно, некоторые домены имеют отношение только к решению, а не к задачам.

Мое понимание пространства задач и решений в DDD. Существует множество других определений.

Новые решения создают новые проблемы, или, говоря словами Simon Wardley, Системы Высшего Порядка Создают Новые Источники Дохода.

Я по-прежнему рекомендую избегать использования термина "задача/пространство" и вместо этого уточнять, что вы на самом деле имеете в виду: цель, среда, климат, доктрина, лидерство или что-то еще.

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

Домены иерархичны

Если домен может содержать поддомены, а поддомен — это домен... то поддомен может содержать поддомены, которые меньше. Домены и поддомены — это иерархическая концепция.

При проектировании социотехнических систем мы часто хотим показать домены на разных уровнях. Руководство организации пожелает отобразить 7 доменов верхнего уровня компании. Архитекторы программного обеспечения возможно посчитают необходимым увидеть границы доменов для 100 микросервисов.

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

Поддомен в сравнении с ограниченным контекстом

Это одна из самых запутанных вещей в DDD, но когда у вас есть четкое определение поддомена, то объяснить его проще всего.

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

Модель в DDD может быть представлена в различных форматах, например, в виде заметок или кода. Все то, что показывает концепции домена, отношения, правила и так далее.

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

Поддомены в сравнении с ограниченными контекстами: Области домена в сравнении с границами моделей домена

Согласны или не согласны?

Согласны ли вы с этими определениями и будете ли использовать их в дальнейшем? Если нет, пожалуйста, оставьте комментарий. Я больше забочусь о создании общего понимания в сообществе DDD, чем о продвижении моих определений в качестве стандартов де-факто. Буду очень рад изменить свое мнение...

Перевод материала подготовлен в рамках курса «Системный аналитик. Basic».

Всех желающих приглашаем на открытый урок «Почему все начинается с требований?». На занятии разберём, зачем нужны требования к ПО и каких видов они бывают. РЕГИСТРАЦИЯ