[Перевод] Парадигма DDD стала гораздо важнее, когда ИИ пишет код за вас

Что бы вы ни думали о программировании с привлечением ИИ, сейчас подходы к созданию ПО меняются. Все задумываются: «Что останется важным»? Сколько людей — столько мнений, но выскажу моё: большинство идей из области предметно‑ориентированного проектирования (DDD) сейчас важны как никогда, поскольку парадигма DDD никогда не ограничивалась кодом как таковым. Чем активнее развивается агентное программирование, тем лучше требуется понимать предметную область, хорошо её моделировать и осваивать командную работу. Давайте поговорим о том, чему такому нас по‑прежнему может научить DDD, чего не в состоянии заменить ИИ.

Обычный дисклеймер: я пишу о сложных проектах, поддерживаемых месяцами и годами, о том, в чём команды испытывают затруднения, и в каких отношениях блещет DDD. Нет никакой нужды использовать такие продвинутые паттерны в пет‑проектах или CRUD.

Что не изменилось с 2003 года

Эрик Эванс опубликовал книгу Domain‑Driven Design более двадцати лет назад, но она до сих пор удивительно свежа. В книге раскрыто множество тем, но основной посыл заключается в том, что в программной инженерии особенно сложно понять предметную область и хорошо смоделировать её в коде. Книга призывает разработчиков не слишком углубляться в технические детали и сосредоточиваться именно на решаемой проблеме, поскольку именно этого добиться сложнее.

В самом деле, талантливый инженер начинает выстраивать выверенные фреймворки, стараясь решить проблемы предметной области технологическими способами. Задача изучать и моделировать предметную область передаётся кому‑то другому. С неотъемлемой сложностью программного обеспечения пытаются справиться в лоб, так как если поступать иначе — есть риск заняться чем‑то нерелевантным.

Эрик Эванс Domain‑Driven Design

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

Тем не менее, по‑прежнему важно знать высокоуровневые программные концепции, чтобы направлять работу агентов и решать, насколько осмысленной получается их выдача. В большинстве случаев именно сложность предметной области (той бизнес‑задачи, которой вы занимаетесь) доставляет больше всего проблем. Есть и хорошие новости — программировать стало как никогда просто, поэтому теперь можно сфокусироваться на решении этих сложных проблем, а не теряться в деталях реализации.

Кроме того, теперь можно не заморачиваться выстраиванием фреймворков (или добавлять всё новые микросервисы или следовать за каким‑либо ещё новомодным трендом), а просто прослеживать бенчмарки модели и оптимизировать конфигурацию агентов так, чтобы она генерировала более качественный код — ценой меньших усилий. Как отмечал Эванс ещё в 2003 году, мы всё равно пытаемся подбирать технологии для решения проблем из предметной области. Достаточно забавно, что в наше время и CEO тоже так считают и двигают компании в этом направлении.

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

Модель предметной области — это не артефакт

Основа DDD — это проектирование на основе моделей. Нужно сделать выжимку из принципов работы системы и сформулировать её в виде модели, которая поддаётся описанию в коде. Модель предметной области — это абстрактная концепция, поэтому и представить её можно по‑разному. Это можно сделать в виде документов, схем и кода, но всё это — упрощения, лишь дающие представление о том, как работает модель. Чтобы создать точную модель, нужно переключаться между проектированием и реализацией, а также итерация за итерацией применять то, что вы уже успели изучить.

В DDD это называется «перемалыванием знаний» (knowledge crunching). Вам понадобятся эксперты‑предметники (те, кто разбирается, как устроен данный бизнес) и инженеры, профессионально создающие софт. Они работают в связке, чтобы понять, что должен делать этот софт, и как реализовать всё необходимое. (Например, сеанс штурма событий строится как воркшоп, на котором разработчики и люди, принимающие решения, картируют устройство бизнеса — при этом удобно пользоваться заметками‑стикерами.)

Такая обрисовка модели — это тяжёлая работа, требующая усилий всей команды, поэтому хочется кому‑то её делегировать. Например, ИИ‑агенты блестяще справляются с исследованиями и аналитикой, могут обращаться к вашим документам, чатам и коду. Кажется, что он мог бы создать за вас модель предметной области, а затем также её реализовать.

Но при таком наивном подходе упускается суть. Ценность разработки модели заключается в том, что вы (и ваша команда) в результате понимаете, как функционирует предметная область. Если ИИ сгенерирует простыню текста, это никак не поможет вам точнее обрисовать бизнес‑проблему. Агент просто создаст для вас впечатляющий артефакт, который никто не будет читать.

Задача написать длинный документ о том, как, возможно, что‑либо сможет работать, никогда не представляла ключевой проблемы. Гораздо чаще софтверные проекты терпят неудачу по другим причинам:

1. Программисты разрабатывают не то, что нужно.

2. Никто не знает, что нужно сделать в первую очередь.

3. Команда пытается сделать всё сразу (разрастание объёма).

Вот в какую ловушку я неоднократно попадал. В инженерных командах легко создаётся впечатление, как будто мы уже разобрались во всех деталях: мы же программисты‑эксперты, знаем наши паттерны и придерживаемся наилучших практик. Нам просто нужен кто‑то (заинтересованный представитель бизнеса или продукт‑менеджер), который нам скажет, что делать.

Но зачастую и у экспертов‑предметников чёткого плана нет. Они знают, какая проблема перед ними стоит, но пока не представляют, как её решать. У них нет полного документа, в котором описывались бы все требования. Разработчик первым делом предлагает: «Хорошо, дайте знать, когда сформулируете предложение, будем на связи». Иными словами, мы вернёмся, когда будет можно заняться нашим любимым делом — программированием (отмечу, что именно эту часть ИИ‑агенты и автоматизируют).

Есть и другая крайность: менеджеры, не являющиеся технарями, пытаются предоставить целостное решение и вручить его команде, чтобы команда занялась её реализацией. Или появился совсем новый тренд: кто‑то при помощи ИИ сгенерирует целую фичу или спецификацию продукта, даже её не прочитает и передаст команде. Таким образом, план как бы существует, но он и близко не готов к выпуску в продакшен. (Если кто‑то возьмётся утверждать обратное — сами проверьте, насколько сложна та вещь, которую, как им кажется, уже можно сдавать).

Во всех этих сценариях никто чётко не представляет, что именно делает. Независимо от того, кто пишет код или как быстро, ценность такого кода на данном этапе невелика.

Напротив, когда вы работаете над моделью вместе, ваша команда вникает в предметную область, и решение принимается согласованно. Разработчики занимаются реализацией, а эксперты‑предметники могут подключиться, если произойдёт что‑то неожиданное или с началом новой итерации.

Даже если большую часть кода вы создаёте с применением ИИ, необходимо глубоко познакомиться с предметной областью, чтобы направлять агента — точно как вы руководили бы коллегой. Не столь важно, как именно вы сконфигурируете агентов или какой именно LLM будете пользоваться — главное чётко представлять себе, как именно будет выглядеть решение. Если бы мне пришлось выбирать, я бы лучше вообще перестал писать код сам, чем перестал продумывать, что именно должно быть сделано.

Сначала проектируйте, потом пишите генерируйте код

Писать свой код всегда было проще, чем читать чужой. Сегодня просто всё принципиально изменилось — агент может с одной попытки выкатить для вас большую фичу. Даже если она работает, вы не представляете, что происходит у неё под капотом.

Теперь мы стали чаще буксовать при ревью кода, но и это не новая проблема. Есть даже что‑то знакомое в том, как будто ты снова имеешь дело с разработчиком‑одиночкой, который готовит для тебя полноценные фичи и выдаёт тебе огромный пул‑реквест. Вы ничего не знаете о том, как спроектирована система, и в её структуре часто попадаются пробелы, о которых никто не задумывался. Ревью пул‑реквеста — это всегда болезненно.

Но есть способ избегать таких ситуаций, я убедился в его работоспособности на многих проектах. Вы проектируете решение и обсуждаете его командно, а только потом садитесь работать над кодом. Сначала поговорим об элементах предметной области: какая задача решается и как предположительно должна работать создаваемая система (см. выше упоминание о перемалывании знаний). Это техническая сторона. После того, как запустите реализацию, уже мало шансов, что всплывёт что‑то неожиданное.

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

После некоторых подобных сеансов ревью пул‑реквестов идёт гладко. Если в комментариях к пул‑реквесту вы не обсуждаете весь дизайн, то работу легко подразделить на небольшие фрагменты. Кроме того, когда фича окажется в продакшене, пробелов в ней будет меньше, так как вы уже договорились о деталях, и каждый понимает, что именно мы выстраиваем.

Может сложиться впечатление, что, пренебрегая проектированием, мы как будто экономим время. Никому не нравятся лишние совещания. Но, если ваша команда впервые узнаёт о новой фиче только из пул‑реквеста, то понадобится гораздо больше времени, чтобы ее отревьюить, обсудить и исправить все проблемы. Поскольку ревью обычно делаются асинхронно, получается много раундов комментариев. Код‑ревью служит дополнительной проверкой и помогает убедиться в корректности реализации, это не дискуссия о том, оправдан ли предложенный подход в принципе.

Кроме того, если сначала работать над проектированием, а потом писать код, то можно более качественно работать с ИИ‑агентами. Если дать агенту больше высококачественного материала, то его выдача будет точнее, а сам этап программирования — короче. Чем больше ваша команда знает о решении, тем легче идёт ревью, даже если весь код вы генерируете.

Находим общий язык с агентами

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

После пары прогонов удалось сэкономить много мегабайт оперативной памяти. Но потом осознал, что память обходится очень дёшево, и обновления позволили нам сократить расходы на $1/месяц. Неудивительно, правда? Я не объяснил агенту, что стараюсь урезать расходы, а просто задал использование памяти в качестве целевого показателя.

Должно быть, вам это знакомо, так как именно это происходит при коммуникации в команде. Те практики, которых рекомендуется придерживаться при коммуникации в команде, работают и при диалогах с ИИ. Кто бы могут подумать, что софт‑скиллы когда‑нибудь пригодятся при обращении с компьютерами?

В DDD для решения этой проблемы применяется ряд идей, связанных с используемым языком.

Во‑первых, выделяется Общий язык: то есть, нужно оперировать одним набором понятий как в разных командах, так и в коде, чтобы все понимали, о чём именно речь.

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

При перемалывании знаний учитывайте, что именно вы причисляете к концепциям предметной области. Типична ситуация, когда одна и та же сущность может называться по‑разному. Выберите название, которым уже пользуетесь, либо подберите более точное. Затем пользуйтесь ими в документах, устной речи и коде.

Не получится выбрать имена раз и навсегда, поскольку язык проекта развивается вместе с самим проектом. Языком нужно заниматься и в ходе сеансов, посвящённых проектированию, и при дискуссиях.

Есть ещё одна идея, непосредственно связанная с общим языком: в крупных системах выбранные вами названия будут универсальными во всех областях. В DDD каждая из таких областей называется ограниченным контекстом. Вашего клиента вы можете расценивать как профиль в контексте поддержки и как пользователя в контексте интернет‑магазина. Внутри каждого контекста все имена должны быть взаимно согласованы, но в рамках всего проекта их навязывать не нужно.

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

Агенты имеют доступ ко всему вашему репозиторию и ищут именно те имена, которые вы им сообщили. Они могут наивно попытаться унифицировать схожие сущности, поэтому разъясните агенту, по каким причинам определённые сущности нужно трактовать отдельно.

Если вы пользуетесь хорошо известными и чётко определёнными концепциями, то вам будет проще выразить, что вы имеете в виду. Это правило работает как при взаимодействии с коллегами, так и при формулировании промптов.

Получив зыбкий промпт, агент может слишком много ресурсов потратить на неверное решение:

Создав пользователя, добавить его в CRM и поддержку

Вы сможете чётче сформулировать цель, придерживаясь точных наименований:

Как только пользователь войдёт на сайт под своим логином и паролем, мы асинхронно создадим: 1) учётную запись пользователя в CRM, 2) профиль пользователя в системе поддержки

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

Разработчики становятся экспертами в предметной области

Модели и агенты постоянно совершенствуются, но полностью доверять им нельзя. Они по‑прежнему допускают ошибки, и нужен человек, полностью отвечающий за проект. Как можно убедиться, что результат работы агента верен?

Доверие и убеждённость, что вы понимаете, что делаете, нарабатывается в ходе погружения в предметную область. Те, кто проектирует систему и понимают, как она работает, могут сообщить вам, не сбоит ли какая‑то её часть.

Разработчики становятся экспертами в той теме, которой занимаются. Осваивают иные навыки сверх умения писать код, а любознательный инженер постепенно интуитивно разберётся даже в сложной бизнес‑области. Если вам нужна помощь в этой области, то вы знаете, к кому обратиться. Вы избавите себя от массы проблем, работая с коллегами, которым можете доверять, зная, что они помогут довести дело до конца, не требуя для этого подробных инструкций.

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

Гораздо интереснее поговорить о том, как опытные инженеры в наше время могут создавать всё более сложные приложения. Например, команда может заменить дорогостоящее стороннее ПО собственной альтернативой. Но насколько мы можем быть уверены, что такая самодельная версия будет работать хорошо?

Можем, поскольку эти разработчики уже приобрели нужные знания, поработав в данной предметной области. Они комбинируют накопленные знания при помощи ИИ и создают собственную версию нужной программы так быстро, что написать её оказывается дешевле, чем оплачивать лицензию. Сверх того, в новую программу можно добавить любые специализированные возможности, которые в данном случае нужны.

Нанимателю также очень выгодно нанимать на работу инженеров, которые в курсе продукта и хорошо знают предметную область. Такие люди могут прояснить непонятные детали и направить дискуссию в верное русло. Всегда было легкомысленно считать, что разработчики — это люди, которые напрограммируют именно то, что вы у них попросите, а сейчас — тем более.

Стремление разобраться в пока не известной предметной области приносит разработчику больше пользы, чем сосредоточение лишь на развитии технических навыков. Работать и получать прибыль будет проще, если вы разбираетесь в бизнес‑задачах, а не просто в совершенстве овладели одним фреймворком.

Не позволяйте думать за вас

Методология DDD демонстрирует, насколько создание софта не сводится к написанию кода. Если вам доводилось работать со сложными системами — уверен, вы не раз в этом убедились.

Эта тема напомнила мне о моей первой работе в ИТ. Как‑то раз я корпел над сложной задачей, часами решая её с карандашом в руке. Наконец, я нашёл решение, хотя и почти не прикасался к клавиатуре. Тогда я был начинающим разработчиком, поэтому словно лишился дара речи: «Надо же, мне платят за то, что я думаю».

Тогда это воспринималось дико, а сейчас — тем более. В те времена мой начальник и бровью бы не повёл, если бы я сказал, что весь день провёл над обдумыванием задачи. Сегодня мы более сосредоточены на видимом результате. Так почему бы не делегировать мышление искусственному интеллекту?

Во‑первых, потому, что я могу судить о степени осмысленности выдачи агента лишь при условии, что сам в прошлом потратил многие часы на обдумывание аналогичных задач.

Иногда на это отвечают, что теперь такой опыт не нужен, поскольку ИИ так или иначе может всё за вас сделать. Опора на ИИ в конечном счёте превратится в новую нормальность, но есть одна проблема, которую я не могу игнорировать. Нужно прокачивать мозг в работе над сложными задачами, а если не думать, то и новых ментальных моделей выстроить не удастся.

Наилучшая аналогия, которую я могу подобрать — это прочтение книги и знакомство с её кратким содержанием. При чтении вы вынуждены размышлять над проблемой часами. Вы медленно выстраиваете в голове сложную модель, постепенно связывая её с другими известными вам вещами. Вы понимаете тему, а не просто прочитываете несколько предложений, которые забудете через десять секунд после закрытия браузера.

Наилучшие практики в этой области пока не выработаны, поэтому самое время поэкспериментировать и посмотреть, что работает, а что нет. Я же пока сочетаю старое доброе решение задач с новыми способами работы над кодом.