Перейти к основному содержимому

Domain Driven Design: что это такое и зачем оно нужно системному аналитику

Domain-driven design (DDD) — подход проектирования системы и её архитектуры, который берет за основу реальный бизнес и то, как он функционирует. Для данного подхода справедливо выражение: нет понимания бизнеса — нет системы и её архитектуры. DDD отлично работает для проектов с очень сложными доменными областями и с запутанной бизнес-логикой, которую с наскока не понять.

Цель DDD​

Цель DDD — создать общий язык, который будет использоваться всеми участниками проекта: заказчиками, пользователями, разработчиками, тестировщиками и т.д. Этот язык должен отражать сущности и понятия предметной области, а также их связи и правила. Такой язык называется повсеместным языком (ubiquitous language). Повсеместный язык помогает избежать недопонимания и неоднозначности при общении между участниками проекта.

Простым языком: DDD — это когда разработчик сначала внимательно слушает не мутные требования бизнес-заказчика, а те слова, которые он употребляет, тем самым определяя предметную область интересов заказчика. Это дело уже можно с яростным энтузиазмом упорядочивать в модель. И уже эту модель можно начинать реализовывать на самом нижнем уровне, добавляя в объектную модель те сущности, названия которых употреблял заказчик. А затем, уже когда заказчик более-менее сам начинает понимать что он хочет — разработчик перекомпоновывает и дорабатывает тот набросок.

Для построения повсеместного языка DDD предлагает разделить предметную область на ограниченные контексты (bounded contexts).

Ограниченный контекст​

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

Зачем это нужно?​

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

Роль системного аналитика в DDD​

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

Когда применять DDD?​

DDD стоит применять, когда:​

  1. Вы работаете с микросервисной архитектурой.
  2. Предметная область сложна и динамична.
  3. Есть необходимость в тесном сотрудничестве между разными участниками проекта.

DDD не стоит применять, когда:​

  1. Предметная область проста и стабильна.
  2. Нет явных экспертов по предметной области.
  3. Система имеет низкую сложность и небольшой объем функциональности.

Книги о DDD​

  1. Вон Вернон. Реализация методов предметно ориентированного проектирования Ссылка
  2. Эрик Эванс. Предметно-ориентированное проектирование (DDD) Ссылка

Статьи о DDD​

  1. Domain-driven design: рецепт для прагматика
  2. Domain-Driven Design: стратегическое проектирование. Часть 1
  3. Domain-Driven Design: тактическое проектирование. Часть 2
  4. Domain Driven Design на практике
  5. DDD: модели вместо требований, 9 лет спустя
  6. Ценности DDD
  7. Как DDD помог нам построить новые ревизии в пиццериях
  8. Блеск и нищета модели предметной области
  9. Design a DDD-oriented microservice

Domain Driven Design