Почему доминирование предметно-ориентированного подхода усилится в эпоху ИИ
Массовое внедрение искусственного интеллекта в процесс написания кода часто ассоциируется с упрощением архитектуры. Однако практика показывает обратное: чем больше ИИ берёт на себя рутинные задачи реализации, тем критичнее становится глубокое понимание предметной области (Domain-Driven Design, DDD). Парадигма, ранее считавшаяся излишней бюрократией для простых проектов, становится фундаментом для управления сложностью, когда за код отвечает не человек, а алгоритм.
# Когда ИИ пишет код: почему DDD важнее, чем когда-либо
В последние годы индустрия программного обеспечения переживает фундаментальный сдвиг. Инструменты на базе больших языковых моделей (LLM) и агентные системы позволяют генерировать рабочий код с беспрецедентной скоростью. Мнения разнятся: от эйфории до скептицизма. Но если отбросить шум вокруг конкретных технологий, возникает один устойчивый вопрос: что останется ключевым навыком разработчика и архитектора? Ответ звучит старомодно, но актуален как никогда — это предметно-ориентированный подход (DDD).
Раньше DDD часто воспринимался как способ борьбы со сложностью кода через абстракции и строгую документацию. В эпоху агентов сложность смещается в другое русло: задача теперь состоит не в том, чтобы написать правильные функции, а в том, чтобы сформулировать правильную проблему и убедиться, что созданное решение её действительно решает. Именно здесь методология Эрика Эванса, опубликованная более двух десятилетий назад, показывает свою вечную ценность.
Смена фокуса: от реализации к моделированию
Главная интуиция, лежащая в основе DDD, заключается в том, что код является лишь артефактом, вторичным по отношению к бизнес-домену. Эрик Эванс предупреждал: «Если вы не знаете, какую проблему решаете, лучший фреймворк не поможет». Сегодня этот принцип звучит иначе: если вы не владеете моделью предметной области, лучший ИИ-агент лишь ускорит построение «каркасной» конструкции, которая будет бесполезна в реальных условиях.
До эры ИИ инженер тратил значительную часть времени на изучение языков, настройку инфраструктуры и борьбу с артефактами окружения. ИИ берет на себя эти технические детали. Теперь разработчики свободны от рутины, но сталкиваются с новой ловушкой: они начинают писать код быстрее, чем могут понять суть бизнес-процессов. Агент может мгновенно сгенерировать функцию для «создания пользователя», но если в команде нет единого понимания того, что именно такое «пользователь» в контексте этой конкретной системы (клиент, сотрудник, абонент, покупатель?), то в коде накопятся противоречия.
ИИ-агенты великолепны в исследовании и анализе, но они не обладают интуицией человека, который годами погружен в предмет. Агент создаст для вас впечатляющий артефакт — документацию или код, — который никто не прочтет. Ценность разработки модели заключается в том, чтобы *понять* процесс, а не просто зафиксировать его на бумаге. Если вы делегируте агенту создание модели предметной области, вы рискуете получить набор непонятных аббревиатур, которые не будут служить руководством к действию, а лишь запутают команду при ревью кода.
Важно различать модель как артефакт и модель как способ мышления. Модель — это не документ, который нужно сдать на утверждение. Это «перемалывание знаний» (knowledge crunching), процесс совместного обсуждения с экспертами предметной области (не с разработчиками, а с теми, кто понимает бизнес), чтобы достичь общего понимания того, как система должна вести себя.
Проектирование до кода: ловушка быстрого пул-реквеста
Один из самых болезненных моментов при работе с агентами — это скорость появления готовых пул-реквестов (Pull Requests). Раньше разработчик мог написать код, а потом потратить несколько дней на ревью, исправление и согласование дизайна. Сегодня агенты генерируют «монолиты» за один проход. Это создает иллюзию прогресса, но скрывает катастрофический дефицит архитектурного диалога.
Когда команда обсуждает только детали реализации (например, «какой метод лучше здесь»), но пропускает стадию обсуждения замысла, она сталкивается с проблемами позже. Ревью кода превращается в пытку: нужно переписывать архитектуру, которую никто не обсуждал. В классическом DDD решение должно быть спроектировано и согласовано командой (часто на доске со стикерами) *до* начала написания кода.
Эта задержка кажется неэффективной на короткой дистанции. Но именно на этапе проектирования выявляются логические противоречия, которые ИИ, следуя инструкциям промпта, неизбежно воспроизведет в коде. Начав с качественного, хотя и схематичного, обсуждения того, как система работает, вы получаете более точный контекст для агента. Чем лучше вы сформулировали задачу, тем точнее будет выдача ИИ и тем меньше времени уйдет на исправление ошибок на поздних стадиях.
ИИ-агенты требуют четких инструкций, аналогичных тем, которые дает менеджер проектами. Они не могут читать мысли или угадывать нюансы бизнес-логике. Если вы не определили терминологию заранее, агент будет теряться. Например, понятие «клиент» может означать «пользователя сайта» в одной части системы и «контрагента по договору» в другой. Без единого языка (Common Language) и четких границ между ограничивающими контекстами (Bounded Contexts) агент начнет смешивать понятия, создавая «спагетти-код», даже если каждая отдельная функция написана грамматически верно.
Язык как инструмент управления сложностью
В DDD ключевым элементом является «общий язык» — согласованный набор терминов, используемых в коммуникации между бизнес-экспертами и разработчиками. В эпоху ИИ этот принцип трансформируется в инструмент управления промптами. Если вы не уверены в названиях сущностей или не можете объяснить, как система ведет себя в крайних сценариях, промпт для агента будет расплывчатым.
Агенты склонны к унификации. Они увидят «пользователя» в базе данных и «пользователя» в системе поддержки и предложат использовать один объект для обоих случаев, даже если в реальности их жизненные циклы несовместимы. Разработчик, глубоко погруженный в предмет, заметит эту ошибку сразу. Агенты могут «не заметить» такой семантический разрыв, если в их контексте (системных инструкциях или документации) нет четкого разграничения.
Поддержание актуальной документации и терминологии становится критически важным. Это не бюрократия, а способ донести сложную логику до алгоритма, который не обладает опытом. Хорошая модель предметной области в DDD — это контракт между командой и реальностью. Когда команда владеет этой моделью, каждый член команды (и агент, работающий под руководством команды) понимает, куда смотрит система и почему она работает именно так, а не иначе.
Что остается за скобками
Важно отметить, что использование DDD не означает отказ от технологий или погружение в сложную инфраструктуру микросервисов для всех проектов. Методология не предназначена для простых CRUD-приложений или пет-проектов. Там, где бизнес-логика проста, агент вполне справится сам. Проблемы возникают на уровне сложных систем, поддерживаемых годами, где команды сталкиваются с долговременными обязательствами и необходимостью масштабирования. Именно в таких случаях DDD, усиленный ИИ, становится не просто полезным, а необходимым условием выживания проекта. Не позволяйте ИИ думать за вас; пусть он пишет код, но вы определяйте смысл.