В Domain Driven Design есть много аспектов связанных с кодом, шаблонами и подходами к проектированию ПО. Это всё правильно и полезно, но вряд ли заказчик оценит то, что вы выделили функцию без side effects в Value Object и покрыли её тестами. Зато заказчику точно будут интересны и важны части DDD, которые связаны с поставкой продукта и коммуникацией.
Я собрал основные моменты, которые помогают программистам наладить общение с заказчиком и создать эффективную модель предметной области в коде:
- Единый язык (Ubiquitous Language) — название переменных, таблиц, названия кнопок в макетах, общение с заказчиком, всё это можно быть только на языке заказчика. Если у заказчика в бизнесе есть термин Агент, в коде он может называться только Agent. Если вы в коде начнёте называть его Customer, Contractor или еще как-то, то при общении с заказчиком будете называть его агентов своими «кастомерами». Со временем заказчику понадобится переводчик, чтобы понимать ваши термины, которыми вы называли его родные бизнес-сущности. Несколько примеров и описание проблемы можно посмотреть в статье Ubiquitous Language и Bounded Context в DDD.
- Модель предметной области (Domain Model) — из единого языка рождается модель предметной области, которая должна быть явно обозначена в коде. Это не анемичная модель, у неё есть поведение, как и у реальных объектов в бизнесе. Доменная модель выражает саму суть бизнеса, она должна быть собрана в одном месте, а не размазана по всему коду проекта.
- Углубленный рефакторинг (Refactoring toward deeper insight) — для создания модели предметной области в объектном анализе рекомендуют из общения с заказчиком, из ТЗ и других источников выделить существительные и глаголы, после чего сделать из них объекты и методы. Наивно полагать, что ваше знание предметной области будет достаточно хорошим, чтобы с первого раза постороить стоящую модель. С погружением в проект, с углублением вашего понимания бизнеса заказчика необходимо совершенствовать и модель.
- Дистиляция модели — для лучшей выразительности из Core Domain нужно убирать всё лишнее, например, выносить части не характерных только для вашей предметной области в Generic Subdomain. В конечном счёте Core Domain проекта является его конкурентным преимуществом, всё остальное можно взять в готовом виде, адаптировать из открытых источников или отдать на аутсорс.
- Ограниченные контекст (Bounded Context) — в подобластях одной отрасли (и одного бизнеса) могут складываться свои термины, даже для одних и тех же понятий. Их унификации — это компромисс. Если вы пойдете на него, то не получите выразительной модели ни в одной из подобластей. Обычно говорят, что модель применима в определенном контексте, причём внутри этого контекста термины модели имеют конкретный чёткий смысл.
Часть подходов, которые описаны в книгах можно попробовать только на проекте, который идет несколько лет. Часть подходов это не конкретные шаблоны, а скорее философия работы с требованиями, принципы выстраивания отношений между командой и заказчиками. Тема DDD довольно большая, но изучать её нужно обязательно. Могу рекомендовать две книги для погружения в тему:
- Классическая книга от Эрика Эванса Domain-Driven Design: Tackling Complexity in the Heart of Software
- Более зрелая книга с большим количеством конкретных примеров наработанных сообществом Implementing Domain-Driven Design
Серия статей «Customer satisfaction для программистов»:
