Что такое DDD?
Domain-Driven Design — это не про базы данных и не про фреймворки. Это про то, как сделать так, чтобы ваш код не выглядел как набор решений, принятых на затянувшемся ретро. DDD — это способ проектирования, который ставит бизнес-домен в центр внимания. Да, именно бизнес, а не ваши любимые паттерны проектирования. Если вы думали, что «Singleton» спасет мир, то у меня для вас плохие новости.
DDD — это про то, чтобы ваш код не только работал, но и был понятен людям, которые будут его поддерживать. А это, как вы знаете, не всегда те же самые люди, что его писали. Поэтому, если вы хотите, чтобы вас не вспоминали через год, изучите DDD.
DDD — это хайповый подход, который мы будем осозновать с годами, думаю, что его будет всё больше в нашей жизни.
Кому следует знать о DDD?
Впринципе, есть доля истины в том, что DDD — это просто модное словечко, чтобы произвести впечатление на будующих коллег при собеседовании. Но давайте разберемся, кому действительно нужно знать об этом подходе и почему.
Ниже я представил роли из свого субъективного опыта, кому важно знать о DDD, порядок по убыванию важности.
1. Архитектор/CTO
— Ответственен за общую структуру системы. Если система для управления банковскими транзакциями разваливается, угадайте, кого будут винить?
— Должен разбивать домен на ограниченные контексты (Bounded Contexts). Например, разделить «Кредитный скоринг» и «Комплаенс проверки».
— Строит мосты между системами, которые ненавидят друг друга. Например, когда древняя банковская система и модный микросервис пытаются обмениваться данными, кто-то должен выступить переводчиком. Представьте, что ваша платежная система думает, что деньги — это числа с плавающей точкой (1.5руб — полтора рубля)(первая ошибка!), а бухгалтерия настаивает на копейках как целых числах (150 копеек). Кто будет объяснять директору, почему в отчетах не сходится баланс?
2. Старший разработчик (Tech Lead)
— Проектирует ядро домена (Core Domain) — самую важную часть системы. Например, логику расчета процентов по кредитам.
— Реализует сущности, агрегаты и доменные сервисы. В финансовой сфере это сущности «Счет», «Транзакция» и «Клиент». Непонимание этих концепций обычно палит разработчика, привыкшего лишь к CRUD-операциям.
— Контролирует, чтобы код не превратился в «анаемичную модель».
3. Бизнес(системный)-аналитик/Продакт-оунер
— Участвует в создании единого языка (Ubiquitous Language). Например, чтобы «кредитный лимит» и «овердрафт» понимались одинаково всеми участниками команды.
— Формулирует требования так, чтобы они отражали реальные бизнес-процессы, а не технические детали. Например, «Клиент может запросить выписку по счету за последние 6 месяцев».
Важно: DDD — это не про технологии, а про мышление. Даже менеджеру продукта полезно понимать основы.
4. Разработчики
— Чтобы понимать, как реализовать доменные модели и сервисы. Например, как правильно реализовать обработку транзакций между счетами.
— Чтобы не писать код, который противоречит бизнес-логике. Например, чтобы система не позволяла клиенту снимать больше, чем доступно на счете. Если ваш код ломает всё, кроме тестов, то поздравляю, вы — мастер антипаттернов.
5. Тестировщики
— Чтобы понимать, как тестировать доменные модели и их поведение. Например, проверять корректность расчета процентов по депозитам. QA может упустить суть, если будет тестировать только кнопки.
— Чтобы писать тесты, которые проверяют бизнес-логику, а не только технические аспекты. Например, тесты, которые проверяют, что транзакция между счетами не нарушает баланс.
Кому это нужно?
Тем, кто работает в сложных доменах
Если вы разрабатываете ПО для финансов, здравоохранения или логистики, то DDD может спасти вас от хаоса. Эти области постоянно меняются, и ваш код должен успевать за ними. Представьте себе, что вы пишете систему для банка, а завтра регулятор меняет правила. Без DDD вы будете переписывать всё с нуля. С DDD — только часть.
Командам, которые работают над пересекающимися частями системы
Если вы устали от того, что ваши коллеги ломают ваш код, потому что «так было проще», то DDD поможет установить границы и правила игры. Например, вы можете сказать: «Эта часть системы — моя, не трогайте её!» И это будет нормально.
Тем, кто хочет, чтобы код отражал реальный мир
Если ваш код больше похож на абстрактное искусство, чем на модель реального мира, то DDD — ваш выбор. Например, если вы пишете систему для магазина, то ваши классы должны называться «Товар», «Заказ», «Покупатель», а не «DataProcessor» или, упаси боже, «Helper».
Почему это важно?
Большинство программ ломается не из-за ошибок в синтаксисе, а из-за того, что команды теряют связь с бизнес-проблемой, которую они должны решать. DDD помогает избежать этого, заставляя инженеров и бизнес-экспертов работать вместе. Это не серебряная пуля, но это лучше, чем ничего.
Вот типичный пример. Вы работаете над системой для страховой компании. Бизнес говорит: «Нам нужно учитывать стаж водителей». Вы добавляете поле «стаж» в базу данных и думаете, что всё готово. Но через месяц выясняется, что стаж бывает общий и безаварийный, и они влияют на расчёт страховой премии по-разному. Если бы вы использовали DDD, то знали бы это с самого начала.
Основные концепции DDD
Разделение контекста (Bounded Contexts)
Разделяйте систему на части, чтобы не сойти с ума. Например, в системе интернет-магазина можно выделить контексты «Каталог товаров», «Корзина» и «Оплата». Это поможет избежать ситуации, когда изменение в одном месте ломает всё остальное.
Аггрегирование (Aggregates)
Управляйте сложностью, группируя объекты. Например, заказ в интернет-магазине может быть агрегатом, который включает в себя товары, адрес доставки и способ оплаты. Это позволяет работать с заказом как с единым целым.
Единый язык (Ubiquitous Language)
Говорите на одном языке с бизнесом. Если бизнес говорит «клиент», то и в коде должно быть «клиент», а не «user» или, что ещё хуже, «entity». Это кажется очевидным, но вы удивитесь, сколько проблем возникает из-за несоответствия терминов.
Где DDD работает, а где нет?
DDD отлично подходит для сложных систем, где важно понимать, что происходит. Но если вы работаете над простым CRUD-приложением, то, возможно, это не для вас. Не пытайтесь натянуть DDD на глобус — это не универсальное решение.
Например, если вы пишете приложение для учёта задач, то DDD, скорее всего, будет избыточным. Но если вы разрабатываете систему для управления цепочками поставок, то без DDD вам не обойтись.
Заключение
Если вы хотите, чтобы ваш код был понятным, гибким и отражал реальный мир, то DDD — это то, что вам нужно. Но помните, что это не магия. Это инструмент, который работает только тогда, когда вы понимаете, как и зачем его использовать.
И напоследок: если вы всё ещё думаете, что DDD — это сложно и не для вас, то, возможно, вы просто не хотите выходить из зоны комфорта. А это уже совсем другая история.
Полезно иметь хоть какое-то представление
* Singleton — одним из самых популярных и спорных паттернов проектирования.
* Bounded Contexts — Ограниченный контекст (bounded context)– это граница, которая окружает ту или иную модель. Это держит знания внутри соответствующей границы, в то же время игнорируя помехи от внешнего мира. А теперь по человечески, это когда система для кредитов считает вас банкротом из-за долга в 50 рублей, а система лояльности в это же время настойчиво предлагает VIP-карту с «эксклюзивными привилегиями». Они живут в разных контекстах, они разделены, изолированы друг от друга.