Domain Driven Design (DDD) - что это такое? И как начать использовать DDD в разработке

05.08.2021 Программирование

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

Что очень важно, DDD не связан с технологиями. Вместо этого речь идет о развитии знаний о бизнесе и использовании технологий для обеспечения ценности. Только когда вы сможете понять бизнес, в котором работает ваша компания , вы сможете участвовать в процессе создания модели программного обеспечения порождая так называемый единый язык (Ubiquitous Language).

Программное обеспечение это не только код. Код редко является конечной целью вашей работы. Код это только средства решения бизнес-задач. Так почему код должен быть на языке отличном от языка бизнеса? DDD подчеркивает что код и бизнес должны говорить на одном языке. Когда барьер преодолён, нет необходимости в переводе или утомительной синхронизации, информация не потеряется. Каждый участник влияет на Бизнес-Домен, не только разработчики. Получающееся программное обеспечение - единственная правда для общего языка.

DDD также обеспечивает основу для стратегического и тактического моделирования. Стратегическое проектирование позволяет точно определить наиболее важные области разработки на основе бизнес-ценностей. Тактическое моделирование нужно для построения работающей Доменной Модели с использование проверенных в бою строительных блоков и шаблонов.

Три столпа DDD

Domain-Driven Design это подход к разработке программного обеспечения, который сфокусирован на трёх основных принципах:

  1. Единый Язык (Ubiquitous Language): Эксперты предметной области (Domain Experts) и разработчики программного обеспечения работают вместе, чтобы создать общий язык для разрабатываемых бизнес-сфер. Тут не может быть противопоставления, это единая команда. Разработка программного обеспечения это инвестиция в бизнес, а не просто статья расходов. Усилия, прилагаемые к созданию Единого Языка (Ubiquitous Language), помогают распространить глубокое понимание Домена (Domain) среди всех членов команды.

  2. Стратегическое моделирование (Strategic Design): DDD направлен на стратегию управления бизнесом, а не только на технические аспекты его работы. Это помогает определить внутренние отношения и системы обратной связи раннего предупреждения. С технической стороны, стратегический дизайн защищает каждую бизнес-услугу, обеспечивая мотивацию для достижения сервис-ориентированной архитектуры.

  3. Тактическое моделирование (Tactical Design): DDD предоставляет инструменты и строительные блоки для итеративной разработки программного обеспечения. Инструменты тактического моделирования позволяют создать программное обеспечение, которое не только предельно корректно, но и является тестируемым и менее подверженным ошибкам.

Единый язык (Ubiquitous Language)

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

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

С распространением DDD, появились новые методы улучшающие и упрощающие процесс создания единого языка (Ubiquitous Language). Самый важный и наиболее часто используемый метод это Событийный штурм (Event Storming).

Определение DDD

DDD это не серебряная пуля; как и все в программном обеспечении, всё зависит от контекста. Старайтесь использовать этот подход чтобы упростить ваш Домен (Domain), а не добавляйте сложности. Если разрабатываемое вами приложение ориентировано на работу с данными и ваши сценарии в основном подразумевают CRUD операции (создание, чтение, обновление, удаление), то вам не нужен DDD. Вам всего лишь нужен интерфейс манипуляцией данными в вашей хранилище.

Если в вашем приложении реализует менее 30 сценариев использования (Use Cases), может вам проще использовать фреймворки Symfony или Laravel, для управления всей бизнес логикой.

Однако, если ваше приложение имеет более 30 сценариев использования, ваша система подвержена движению в сторону Большого Комка Грязи (Big Ball of Mud). Если вы точно знаете что ваша система будет достаточно сложной, то вам следует рассмотреть возможность использования DDD для борьбы с этой сложностью.

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

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

Некоторые нюансы

Применять DDD не просто. Необходимо время и усилия, чтобы построить бизнес-домен, создать терминологию, провести исследования и организовать сотрудничество с экспертами предметной области используя единый язык, без профессиональных терминов программистов. Вам потребуется участие экспертов предметной области. Это в свою очередь потребует открытого, здорового и непрерывного диалога, чтобы успешно перенести их терминологию в модель программного обеспечения. Вдобавок ко всему, вам придется приложить усилия, чтобы избежать технических моментов реализации на начальном этапе, а сосредоточиться в первую очередь о поведении объектов и создании единого языка (Ubiquitous Language).

Стратегический обзор

В пространстве задач, DDD использует такое понятие как домены (Domains) и субдомены (Subdomains) для группировки и организации того, что компания хочет решить (реализовать). В случае онлайн-агентства путешествий (OTA), проблема заключается в том, чтобы иметь дело с такими вещами, как авиабилеты и бронирование гостиниц. Такой домен может бы организован в разные субдомены, такие как: ценообразование, инвентаризация, управление пользователями и др.

В пространстве решений, DDD предоставляет два паттерна: Ограниченный Контекст (Bounded Context) и Карты Контекста (Context Map). Целью является то, чтобы определить, как обеспечить реализацию для всех идентифицированных поддоменов путем определения их взаимодействия друг с другом и деталей этих самых взаимодействий. Продолжая пример OTA каждый из поддоменов будет решен с помощью реализации ограниченного контекста - например, рассмотрим пользовательское веб-приложение, разработанное командой для субдомена Управления Пользователями.

Карта контекста покажет, как каждый из Ограниченных контекстов связана с другими. Внутри Карты Контекста, мы можем видеть, какой тип отношений имеют два Ограниченных Контекста (пример: клиент-поставщик (customer-supplier), партнеры (partners)). Идеальный подход состоит в том, чтобы каждый Субдомен реализовывался одним ограниченным контекстом, но это не всегда возможно. С точки зрения реализации, следуя DDD, вы получите распределенные архитектуры. Как вы, возможно, уже знаете, распределенные архитектуры более сложны, чем монолитные, так почему такой подход интересен, особенно у больших и сложных компаний? Это действительно стоит того? В общем, да, это того стоит.

Подтверждено, что распределенные архитектуры увеличивают общую производительность компании, поскольку они определяют границы вашего продукта, которые будут разрабатывать целевые команды разработчиков. Если ваш домен (проблема которую вам нужно решить) - не сложный, то применение стратегической части DDD может добавить ненужные накладные расходы и замедлить скорость разработки. Если вы хотите узнать больше о стратегической части DDD, вам следует взглянуть на первые три главы книги Вона Вернона "Реализация методов предметно-ориентированного проектирования" или книгу Эрика Эвинса "Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем"

Выводы

  • DDD - это не про технологию; на самом деле речь идет о предоставлении результатов в той области в которой вы работаете, сосредоточившись на разработке модели. Каждый принимает участие в процессе проектирование Домена, и разработчики и Эксперты Предметной Области объединяются для создания базы знаний, используя один и тот же, Единый Язык (Ubiquitous Language).

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

  • DDD имеет смысл только в определенных задачах. Это не серебряная пуля для любой проблемы в ПО, поэтому использовать подход или нет, во многом зависит от сложности, с которой вы столкнётесь.

  • DDD - это долгосрочная инвестиция; это требует активных усилий. Эксперты Предметной Области должны тесно сотрудничать с разработчиками, а разработчики должны думать с точки зрения бизнеса. В конечном итоге клиенты бизнеса - это те, кто должен быть довольны вашей работой. Реализация DDD требует усилий. Если бы это было легко, все писали бы качественный код. Будьте готовы, потому что вы скоро узнаете, как писать код, который при прочтении отлично описывает бизнес вашей компании.