Почему DDD важнее, чем когда-либо, в эпоху ИИ-кодинга

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

Одной из главных проблем в индустрии является разрыв между намерениями бизнеса и технической реализацией. Часто команды попадают в ловушку, где разработчики ждут четких спецификаций, а менеджеры не могут их предоставить, либо же ИИ генерирует код по размытым запросам, создавая «впечатляющие артефакты», которые никто не понимает. Автор подчеркивает, что ценность модели предметной области заключается не в самом документе, а в процессе совместного осмысления проблемы командой. Это так называемое «перемалывание знаний» (knowledge crunching), где эксперты-предметники и инженеры совместно определяют, как должна работать система. Без этого этапа ИИ просто генерирует код, который может быть технически корректным, но бизнес-непригодным.

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

Ключевым инструментом DDD в контексте работы с ИИ является «Общий язык» (Ubiquitous Language). В крупных системах одна и та же сущность может называться по-разному в разных отделах. Например, «клиент» в поддержке — это не то же самое, что «пользователь» в интернет-магазине. В DDD такие различия формализуются через понятие «ограниченных контекстов». Для ИИ-агентов это критически важно: если промпт содержит размытые термины, агент может потратить ресурсы на неверную интерпретацию задачи. Четкое определение понятий и их последовательное использование в коде, документации и устной речи позволяет агентам точнее понимать контекст и генерировать более релевантный код.

Автор приводит пример оптимизации памяти в сервисе на Go. Изначально агенту было поставлена задача снизить потребление памяти, что дало минимальный экономический эффект ($1/месяц). Проблема заключалась в том, что не была сформулирована истинная бизнес-цель — снижение общих облачных расходов. Это иллюстрирует, как технические метрики без привязки к бизнес-логике приводят к неэффективным решениям. Коммуникационные навыки, которые раньше применялись только во взаимодействии с коллегами, теперь становятся обязательными для эффективного диалога с машинами.

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