DDD без суеты: стратегия важнее кода

Многие разработчики (и даже AI-агенты!) сводят Domain-Driven Design (DDD) к набору модных паттернов: Entity, Aggregate, Repository, Factory, Service, Value Object, Bounded Context, Domain Event. В соцсетях полно гуру с тремя годами опыта, которые вещают о микросервисах и DDD, сыпля терминами. Но давайте разберемся: действительно ли DDD — это про код? Спойлер: нет.

Почему DDD — это не про паттерны кода

Вон Вёрнон в своей «Красной книге» прямо пишет: DDD — это про обсуждение, слушание, понимание, открытие и бизнес-ценность, а цель — централизация знаний. Если вы этого не делаете — вы не занимаетесь DDD, точка.

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

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

Тактические инструменты — опциональны

Можно ли заниматься DDD без тактических инструментов? Да. Можно ли без стратегических? Нет. Тактические паттерны (Entity, Aggregate и т.д.) — это лишь возможные инструменты, но не суть.

Ключевой вопрос, на который отвечает DDD: «Можете ли вы предсказать, какие части системы и кода будут меняться чаще всего?» Подразумевается, что части, приносящие максимальную бизнес-ценность и отличающие вас от конкурентов, будут меняться чаще всего. Поддерживающие модули (аутентификация, профили) обычно меняются реже.

Стратегические паттерны — критичны

Стратегическая часть DDD — это понимание, какие части системы важны, а какие нет. Например, для торговой платформы банка: управление профилем клиента? Аутентификация? Интеграция с внешними банковскими системами? Очевидно, что первые две — не главные. Они не дают дифференцированной бизнес-ценности, а лишь поддерживают систему.

Никто не бросит пользоваться торговой платформой из-за невозможности загрузить аватар, но все бросят, если она неправильно рассчитает сделку и деньги пропадут. Именно здесь — «секретный соус» бизнеса, и именно здесь нужно применять все лучшие практики.

Типичная ошибка: «энтайтить и сервисить всё»

Многие разработчики используют Entity, Aggregate, Service, Repository для создания простого модуля управления профилем. Это как строить ракету, чтобы доехать до соседнего магазина.

Вёрнон пишет: «Бизнес регулярно вкладывает слишком много усилий в создание приукрашенных редакторов таблиц БД. Без правильного выбора инструментов CRUD-решения, реализованные излишне сложно, обходятся слишком дорого... если выбор правильный, это экономит время и деньги».

Посмотрите на свой бизнес: вторичные продукты разрабатываются просто (например, через CRUD)? Укладываются в бюджет? Быстро создаются? Экономят деньги и время? В моем опыте, чаще всего нет. Если организация «делает DDD», она использует агрегаты, сущности, репозитории повсюду — это неправильно.

Стратегическое проектирование как защита от изменений

DDD помогает ответить на вопрос: «Где сосредоточить усилия?» Это как инвестиции: предсказывать судьбу отдельной акции сложно, а вот инвестировать в индексный фонд — проще и надежнее. Bounded context и домены — это более крупные куски бизнеса, о которых вы делаете прогнозы.

Практический подход: определите домены и части бизнеса. Какие из них вряд ли изменятся? Не заморачивайтесь с ними, возможно, купите готовое решение. Какие части — «секретный соус», который будет часто меняться? Если этот домен действительно сложный, тактические паттерны могут помочь.

Откуда взялась проблема?

Почему так происходит? Возможно, разработчики любят усложнять. Или руководители не технические и не думают о законе Конвея. Или нет доступа к людям, чью работу вы автоматизируете. Или все хотят быть контент-креаторами и говорить о трендах. Или настоящий DDD сложен, требует реального опыта и зависит от контекста бизнеса, что трудно воспроизвести, поэтому мы хватаемся за то, что можно скопировать, чтобы звучать умно. Или эпоха «легких денег» позволяла тратить ресурсы впустую, нанимая людей и закидывая их деньгами, делая вид, что все хорошо.

Как это исправить?

Я не уверен, как «исправить» это в глобальном масштабе. Нужно, чтобы отдельные люди меняли свое мышление и помогали другим. Это часть более широкой дискуссии о переусложнении систем. Ваш код, скорее всего, не так важен для бизнеса, как вы думаете. Шансы, что вы переусложнили архитектуру, высоки. Но непонимание существует вокруг agile, TDD, SOA и всего остального. Это проблема людей.

Практический вывод: что делать прямо сейчас

1. Поговорите с бизнес-экспертами — с теми, кто реально делает работу, которую вы автоматизируете. Узнайте, что для них действительно важно.
2. Определите домены — какие части системы приносят дифференцированную ценность, а какие — просто поддержка.
3. Сосредоточьте усилия — вложите ресурсы, время, качество и дизайн в те места, где это действительно важно. Для вспомогательных модулей используйте простые решения (CRUD, готовые библиотеки).
4. Не злоупотребляйте тактическими паттернами — используйте их только там, где домен сложен и постоянно меняется.

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