DDD. Что это такое?

Статьи серии:

DDD. Что это такое?
DDD. Единый язык. Ubiquitous language

Результаты опроса:

Итак, приступим!

DDD - Domain Driven Design - Предметно-ориентированное проектирование.

Я уже делал статью про Domain Driven Design, но она является очень highlevel overview на тему DDD с кучей ссылок и определений. Первая статья полезна лишь как справочник материалом. Стоит исправить это недоразумение и разобраться в вопросе подробно.

Итак, я хочу написать серию статей про DDD, где попробую описать DDD (Domain Driven Design). От простого к сложному, подробно останавливаясь на каждом аспекте с примерами.

Что такое DDD?

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

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

«Организации проектируют системы, которые копируют структуру коммуникаций в этой организации»
- Мелвин Конвей

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

Почему появился DDD и какие проблемы он решает?

Здесь ответ короткий и вполне очевидный - для борьбы со сложностью в больших приложениях.

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

Основные проблемы решаемые DDD:

• размазанная логика бизнес-процессов
• сущности которые описывают всё (god object)
• зависимость от инфраструктуры хранения, обработки, передачи данных

Основные концепции, DDD keywords?

Приведу, как мне кажется, основные концепции Domain Driven Design и это будет отправной точкой для дальнейшего исследования.

• Единый язык
• Доменная модель
• Ограниченный контекст

Единый язык

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

Доменная модель

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

SQL или NoSQL, PostgreSQL или MongoDB, JSON или XML, Java или Python - это все не важно на уровне доменной модели, она не зависит от этого и ничего про это не должна знать.

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

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

Интересный момент - это то, что могут существовать контексты, содержание одну и туже "сущность", что приведет к дублированию кода и данных в хранилище. У этого есть свои плюсы и объяснение почему так стоит делать, но об этом в статье про Bounded Context.

Как это работает?

Основная идея:

• Доменная модель не зависит ни от чего.
• Доменная модель отражает предметную область.
• Доменная модель предоставляет реализацию бизнес-процессов.

Сначала мы исследуем предметную область, выделяем "Bounded Context"ы и результатом нашей работы является доменная модель. Доменная модель - это главное, что у нас есть.

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

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

Заключение

Начало положено, продолжение следует...

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