Разработка с использованием Domain Driven Design

Первостепенная задача разработчика — решение проблем пользователей, написание кода —только инструмент.

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

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

DDD (domain driven design) — предметно-ориентированная парадигма проектирования и разработки — помогает решить данную проблему с помощью особого подхода к проектированию и коммуникации.

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

Ключевые понятия DDD

  • Domain Model (Модель) — структурированные знания об определенной предметной области.
  • Переработка знаний — получение информации о предметной области в понятной и структурированной форме. 
  • Непрерывное обучение —постоянное изучение предметной области в процессе формирования модели и общения со специалистами и пользователями.
  • Единый язык —общий и понятный всем язык общения. Является хранилищем переработанных знаний о предметной области.

Domain Driven Design использует слоистую архитектуру. Её главным компонентом является смысловое ядро — Core domain — часть домена, имеющая первостепенное значение для выполнения главной задачи.

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

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

Преимущества разработки по Domain Driven Design

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

Ошибки в модели предметной области критичны, поэтому успешная реализация требует:

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

Важно понимать, что DDD не говорит, как писать код, то есть не исключает ни одну из практик, или принципов разработки, таких как SOLID, KISS и так далее.

DDD в итеративной разработке

В итеративной разработке проект разбивается на несколько логически цельных итераций. В каждой итерации проект проходит цикл «Планирование → Реализация → Проверка → Корректировка».

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

Как правило первая итерация представляется собой минимально достаточное смысловое ядро — основной домен проекта и набор прикладной функциональности.

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

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