Повторение основ доменно-ориентированного проектирования

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

Отказ от ответственности

Как я только что сказал, некоторые вещи, которые я собираюсь написать, являются только моим мнением. Многие из вас могут не согласиться с некоторыми из них. Эй, когда мы в последний раз говорили об этом, Эрик и Вон не были поклонниками моей теории. Но, тем не менее, он основан на моем 7-летнем путешествии по DDD в нашей компании, и он у меня работает. Я верю, что это может сработать и для вас.

доменов

Термин «Домен» определяет общую сферу деятельности компании. Например, в Internovus мы занимаемся маркетингом для наших клиентов. Мы разрабатываем маркетинговые стратегии, покупаем рекламные места, создаем креативы, проводим рекламные кампании, связываемся с лидами и закрываем продажи. Мы приводим новых клиентов к нашим клиентам. Поэтому наш Домен — Приобретение Клиентов. Домен Netflix — развлечения. Конечно, компания может работать в разных всеобъемлющих областях. Например, Amazon начинала с розничной торговли, но в настоящее время облачные вычисления также являются доменом Amazon.

Поддоменов

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

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

Типы субдоменов

Не все поддомены одинаковы. Их можно разделить на три типа: общие, основные и вспомогательные.

Общие поддомены

Общие поддомены — это то, что все компании делают одинаково. Они считаются «решенными» проблемами.

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

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

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

основных субдоменов

Основные поддомены — это секрет вашей организации. Это то, чего больше никто не делает или делает по-другому. Они приносят конкурентное преимущество вашей компании.
Компании хотят получить конкурентные преимущества с высокими входными барьерами. Никто не станет инвестировать в то, что могут быстро скопировать их конкуренты. Поэтому по своей природе поддомены Core являются сложными. Их бизнес-логика сложна, и обычно она часто меняется, так как со временем оптимизируется.

Технические решения должны соответствовать бизнес-сложности поддоменов Core. Здесь вы хотите реализовать самые сложные шаблоны моделирования бизнес-логики. Вы хотите анализировать и оптимизировать бизнес-эффективность ваших алгоритмов. Для этого вам нужно назначить лучших людей для работы над ними. Вы не хотите рисковать с поддоменами Core.
На рынке могут быть доступные решения, но вы не хотите их покупать. По определению, в поддоменах Core вы делаете что-то отличное от ваших конкурентов. В противном случае у вас не было бы конкурентного преимущества.

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

Поддержка субдоменов

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

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

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

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

Но что, если это нельзя упростить? Вот где все становится интересно. Если вспомогательный домен сложен и для его сложности есть причины, то это может быть замаскированный поддомен Core. Бизнес может получить дополнительное конкурентное преимущество благодаря этому субдомену.

Побочное примечание: домены против. Поддомены

В «Синей книге» термины «домен» и «субдомен» взаимозаменяемы (например, «основной домен» и «общий субдомен»). На мой взгляд, эта формулировка вызывает путаницу; поэтому я предпочитаю использовать Домен для определения структуры бизнеса компании, а Субдомены — для определения отдельных областей бизнеса, необходимых для достижения успеха в Домене компании.

Примечание: оценка сложности

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

• Похожа ли система на интерфейс CRUD и описывается ли экспертами предметной области в терминах CRUD? — Простой
• Вращается ли бизнес-логика вокруг проверки ввода? — Простой
• У вас есть сложные алгоритмы и расчеты? — Комплекс
• Есть ли у вас бизнес-правила и инварианты, которые следует применять? — Комплекс
• Какой будет цикломатическая сложность полученного кода? Есть ли у него много различных сценариев выполнения? — Комплекс

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

Также важно отметить, что сложность поддомена не является абсолютной величиной. Это во многом зависит от потребностей данной компании. Например, вышеупомянутый каталог креативов довольно прост для Internovus — нам просто нужен способ каталогизировать эти файлы. Но для другой компании, специализирующейся на каком-то умном способе управления и индексации творческих материалов, та же работа была бы на порядки сложнее. Следовательно, Creatives Catalog будет основным субдоменом этой компании.

Особые случаи

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

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

НО ЭТО НЕ ТО, ЧТО ГОВОРИТ СИНЯЯ КНИГА!!!

«Все модели ошибочны, но некоторые из них полезны». В сообществе DDD мы склонны повторять эту цитату как мантру, но забываем применить ее к нашим собственным проблемам и методам. Мое представление о доменах и поддоменах — это не абсолютная истина, а всего лишь модель. Некоторые говорят, что это неправильно. Конечно, все модели ошибочны! Но я нахожу его полезным во многих отношениях.

Простая категоризация

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

Можете ли вы купить/принять готовый продукт, не ставя под угрозу конкурентное преимущество компании? — Общий поддомен.

Бизнес-логика проста? — Поддержка субдомена.

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

Объединение деловых и технических сложностей

Этот способ категоризации поддоменов позволяет привести сложность технического решения в соответствие со сложностью бизнес-поддомена.

Для поддоменов ядра используйте тяжелую артиллерию. Реализуйте модель предметной области или модель предметной области, основанной на событиях. Вам нужна их способность справляться со сложностью.

Для поддержки поддоменов используйте простые решения. Достаточно сценариев Transaction Script или Active Record. Кроме того, это поддомены, которые вы можете передать на аутсорсинг, не ставя под угрозу бизнес.

И, конечно же, общие поддомены дешевле купить или принять, чем внедрять самостоятельно.

Диалог с бизнесом

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

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

Резюме

Этот способ определения поддоменов оказался для меня наиболее выгодным. Он отличается от «того, что говорит Синяя книга», но по вышеупомянутым причинам я считаю этот метод очень полезным. Поэтому я призываю вас попробовать и поделиться своими результатами.

Домен, поддомен, ограниченный контекст, пространство проблемы/решения в DDD: четко определено | Ник Тьюн | Стратегия, архитектура, непрерывная поставка и DDD

Опубликовано в

·

Чтение: 8 мин.

·

25 ноября 2020 г. создание общий язык между экспертами в предметной области и сборщиками систем. К известным принципам DDD относятся «Использование вездесущего языка» и «Сделайте неявное явным».

Если вам понравилась эта статья, вам может понравиться и другая статья, которую я написал: Что такое домен?

Я также очень рекомендую книгу Германа Пирена «Почему мне не нужен ограниченный контекст».

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

Также стоит иметь в виду, что DDD был опубликован в 2004 году, в то время, когда полноправные кросс-функциональные команды по разработке продуктов были редкостью. В то время IT был отдельным отделом от «бизнеса».

Этот пост основан на долгом разговоре на github с участием многих людей из сообщества DDD.

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

Под нечетким я подразумеваю, что слово может использоваться для описания различных вещей, которые в чем-то похожи, но не идентичны. Слово «мало» — хороший пример. В некоторых сценариях это может означать низкий диапазон, например 2–3, а в других — другой диапазон, например 5–10. В других случаях это может означать 100 фунтов стерлингов «не могли бы вы одолжить мне несколько фунтов?». Ключевым моментом является то, что нечеткость должна быть легко выведена из контекста (если разные люди интерпретируют ее существенно по-разному, это слишком двусмысленно).

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

Авторы и права: Джефф Паттон https://www.jpattonassociates.com/read-this-first/

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

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

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

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

она лечила бизнес 9 0169 как ее частный домен .

Эти документы являются в общедоступном домене (= доступный для всех).

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

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

Как сгруппировать эти понятия в домены?

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

Мы можем сгруппировать квадратные фигуры в область Квадратов , а круги в область Кругов . Но синий квадрат и синий кружок также могут принадлежать домену Blue .

Одни и те же концепции могут относиться к разным предметным областям

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

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

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

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

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

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

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

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

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

Возможно, самая запутанная и противоречивая тема — это субдомены и ограниченные контексты. Два типа границ.

Некоторые люди предполагают, что поддомены являются частью проблемного пространства, выбранного «Бизнесом», тогда как ограниченные контексты — это границы программного обеспечения, определенные инженерами.

Мне это кажется очень устаревшим. И это имеет смысл. DDD был опубликован 20 лет назад, в то время, когда произошел раскол между бизнесом и отдельным ИТ-отделом. Был большой разрыв между границами бизнеса и программным обеспечением.

Но в современных организациях, ориентированных на продукт, это уже не имеет смысла. ИТ встроены в «бизнес». Отдельной ИТ-команды нет. Команды инженеров, наделенные полномочиями, владеют продуктами, которые они создают, и формируют топологию своей собственной команды. Границы бизнеса, организации, домена и программного обеспечения определяются одними и теми же людьми.

Наиболее запутанные термины — пространство проблем и пространство решений. У всех разные взгляды на то, что находится в пространстве проблем и что находится в пространстве решений в контексте предметно-ориентированного проектирования.

Я думаю, что модель пространства проблемы/решения слишком упрощена для того, что пытается выразить DDD. Это слишком неоднозначно и требует большей точности. Элементы цикла «Стратегия» Саймона Уордли, на мой взгляд, гораздо полезнее.

Стратегический цикл Саймона Уордли

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

• Цель : какая проблема решается / цель, которую необходимо достичь в нашей интересующей области (областях)?
• Ландшафт : каково текущее состояние домена(ов), которые нас интересуют
• Климат : какие силы действуют на домен(ы) и как они могут развиваться
• Доктрина : универсальные передовые методы, которые мы должны применять
• Лидерство : каково наше решение… какие изменения мы собираемся внести в существующие и новые домены

Домены/поддомены: проблема или пространство для решения?

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

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

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

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

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

Новые решения создают новые проблемы, или, по словам Саймона Уордли, системы высшего порядка создают новые источники ценности.

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

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

Иерархические домены

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

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

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

Домены иерархичны и представляют бизнес-возможности.

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

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

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

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

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

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

This entry was posted in Популярное