Будущее web-разработки для веб-студий и digital-агентств: проектная разработка клиентских сайтов в эпоху ИИ

Ниже — мои рассуждения про будущее web‑разработки, но не в абстрактном смысле типа «что будет с React или с PHP», а в очень прикладном контексте: проектная разработка клиентских сайтов для веб‑студий и digital‑агентств.

Под «клиентскими сайтами» я имею в виду то, что составляет основу студийного портфеля: корпоративные сайты, витрины, каталоги, промо‑лендинги, спецпроекты и e‑commerce среднего уровня. Это проекты, которые живут в логике сроков и бюджета, развиваются итерациями и почти всегда упираются в контент/SEO, интеграции и поддержку «волнами».

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

Вступление: почему «будущее web» — это про экономику изменений

Когда говорят «будущее web‑разработки», часто обсуждают тренды: SSR/edge, новые фреймворки, очередной виток low‑code/no‑code, новые CMS. Но реальный перелом последних лет — не про технологию как таковую, а про экономику производства артефактов.

ИИ радикально снизил стоимость генерации:

• кода (включая рутину),

• тестов (как минимум каркасов и сценариев),

• текстов и контента,

• интеграционной «обвязки»,

• документации и примеров.

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

А вот что стало дефицитом — это:

• согласованность,

• предсказуемость,

• проверяемость,

• способность менять правила, не ломая систему.

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

Если упростить: будущее web‑разработки — это про то, как удерживать систему в целостности при высокой скорости изменений.

1. Что реально меняется из-за ИИ: производство артефактов становится массовым

Я бы выделил три практических эффекта, которые уже видно и которые будут усиливаться.

1) Код, тесты, тексты, шаблоны и интеграции генерируются быстрее

Это плюс: быстрее прототипировать, быстрее закрывать типовые задачи, быстрее выпускать итерации.

2) Риск расхождений и фрагментации растёт

Когда что‑то становится дешёвым, оно начинает производиться массово. Массовое производство без стандартов почти всегда порождает:

• разные «варианты истины» в разных местах (тут одно правило, там другое),

• дубли логики («быстрее скопировать, чем разобраться»),

• несовместимые куски интеграций,

• «скриптовый зоопарк» вокруг CMS или вокруг фреймворка.

ИИ усиливает эту тенденцию. Он ускоряет не только «хорошие практики», но и «плохие привычки». Если у команды нет рельс, по которым она ездит, ИИ не сделает дисциплину за неё.

3) Новый дефицит: единая модель, контракты, проверяемость

Самое ценное становится не «сгенерировать очередной компонент», а:

• иметь единый язык (термины),

• иметь место, где живут правила (инварианты),

• иметь контракты на взаимодействия,

• иметь проверки (тесты/CI), которые удерживают систему от расползания.

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

2. «Чистый код» как актив: доменные инварианты вместо вкусовщины

Про «чистый код» часто спорят как про эстетику. Я предлагаю смотреть прагматично: чистота кода — это снижение стоимости изменений.

В проектной разработке клиентских сайтов домен есть почти всегда, просто он не всегда осознан. Домен проявляется как набор правил:

• как формируется оффер (в зависимости от сегмента),

• как применяются акции и исключения,

• как считается цена/стоимость/пакет,

• какие статусы есть у заявки и что они значат,

• какие поля обязательны и почему,

• как синхронизируется каталог,

• какие данные считаются «истиной» (CRM? CMS? учётка?).

Эти правила и есть инварианты: то, что должно оставаться истинным при любом количестве «быстрых правок».

Где нужен домен (и где точно не нужен)

Домен нужен, когда:

• правила сложные и часто меняются,

• интеграций много и они критичны,

• ошибка стоит дорого,

• поведение должно быть воспроизводимым,

• команда сменяемая, проект долгоживущий.

Домен не нужен, когда сайт в основном контентный, а правила редкие и очевидные.

✅ Чек-лист: «Где нужен домен на клиентском сайте»

Используйте доменный слой (хотя бы минимальный), если есть 3+ пункта:

1. Правила меняются чаще, чем раз в квартал.

2. Есть несколько источников данных (CRM/ERP/каталоги/фиды/прайсы).

3. Ошибки дороги: деньги, репутация, юридические последствия.

4. Есть состояния и жизненный цикл (заявка/бронь/договор/статус).

5. Логика распределена между админкой, фронтом, интеграциями и её сложно объяснить.

6. Одно правило нужно в нескольких местах (сайт, ЛК, CRM, рассылки).

7. Есть персонализация/сегментация.

8. Нужны эксперименты (A/B) без риска «сломать базу».

9. Есть «исключения» и «кроме».

10. Команда меняется, проект живёт годами → нужен «якорь» знаний.

Как сделать «богатый слой» минимальным и окупаемым

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

Что именно в доменном слое должно быть «чистым», чтобы стать активом для ИИ

Если говорить прикладно, ИИ «любит», когда доменный слой устроен так, что правда системы выражена явно, а не размазана по контроллерам, шаблонам, ORM и интеграционным скриптам. Тогда домен становится не просто кодом, а опорой, вокруг которой можно безопасно строить генерацию тестов, спеки, документации и экспериментов.

Вот набор свойств, которые превращают доменный слой в актив (и для команды, и для ИИ):

1. Явные типы и ограничения
   Value Objects вместо «string/int везде». Деньги, даты, статусы, идентификаторы, сегменты, периоды акций — всё, что критично для правил, должно иметь тип и валидацию.
   Смысл не в «красоте», а в том, что ИИ и человек одинаково хуже ошибаются, когда ошибка невозможна структурно.

2. Инварианты в одном месте
   Правила не должны жить одновременно в UI, в хендлерах, в ORM‑хуках и в «настройках модуля».
   Инвариант должен быть закреплён в агрегате или доменном сервисе так, чтобы его можно было прочитать и проверить в тесте.

3. Доменный язык вместо технического
   Имена методов, команд и событий должны совпадать с бизнес‑терминами: ApplyPromotion, CalculateOffer, LeadQualified, BookingExpired.
   Когда в домене появляются processData() и handleRequest(), это почти всегда симптом: правила скрыты, а смысл потерян.

4. Детерминированность и тестируемость
   Там, где можно, доменная логика должна быть чистой и предсказуемой: одна и та же команда при одних и тех же входах даёт один и тот же результат.
   Время, рандом, I/O, внешние API — выносятся наружу. Это упрощает тестирование и делает генерацию тестов/спеки гораздо надёжнее.

5. Событийность там, где нужен след изменений
   Доменные события — это «аудит смысла», а не просто лог.
   Если вы фиксируете OfferCalculated, PromotionApplied, LeadCreated, вы получаете объяснимость поведения: другим командам (и ИИ) проще строить документацию, тесты, сценарии и аналитические проверки, не читая весь код.

Если коротко: такой домен становится вашей «обучающей выборкой» — и для новых разработчиков, и для ваших AI‑инструментов. На грязном домене ИИ тоже может ускорять разработку, но он ускоряет и расхождения.

3. Spec/doc-driven в 2026+: спека как то, что «ест» ИИ

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

Спека как интерфейс между бизнесом, командой и ИИ

Для студийного проекта часто достаточно, чтобы спека фиксировала:

• термины,

• сценарии,

• входы/выходы,

• ограничения (инварианты),

• ошибки и крайние случаи,

• примеры данных,

• критерии приёмки.

Как спека превращается в тесты, моки, SDK, документацию

Если спека формализована (OpenAPI/JSON Schema/AsyncAPI или хотя бы строгая структура use‑cases), дальше появляется конвейер:

• мок‑серверы,

• SDK,

• контрактные тесты,

• документация.

Почему «бумажные спеки» умирают

В мире высокой скорости изменений «бумажная спека» неизбежно отстаёт. Остаётся устойчивый вариант: исполняемые артефакты, которые проверяются в CI.

4. Обратный вектор: code-first документация поверх доменной модели

Как извлекать из кода: термины, сценарии, ошибки, контракты

Если доменный контур сделан хотя бы минимально дисциплинированно (явные типы, явные ошибки, явные use‑cases), из него можно извлекать:

• словарь терминов,

• каталог use‑cases,

• контракты API,

• список доменных ошибок,

• примеры входов/выходов.

Docs-as-code и CI: чтобы документация не врала

Документация должна быть частью репозитория и частью CI:

• изменили правило → обновили док,

• изменили контракт → CI проверил совместимость.

Контур: Model → Spec → Generation → Tests → Model

Смысл в замыкании цикла: спека не «висит рядом», она проверяется и возвращает обратную связь в модель. Это делает систему устойчивой при высокой скорости изменений.

Практика: как «навесить» spec/doc/test-генерацию на доменный код

Самая устойчивая схема в 2026+ выглядит так: мы не пишем спеки «отдельно», мы строим их вокруг доменной модели и use‑cases, и заставляем CI проверять, что спека и код не разошлись.

Минимально жизнеспособный стек дисциплин (без фанатизма), который реально окупается в проектной разработке клиентских сайтов:

1. Contract tests для API и интеграций
   Вариантов два, и оба рабочие:
   — schema‑level (OpenAPI/JSON Schema) + валидация входов/выходов в тестах;
   — consumer/provider (где это оправдано), чтобы изменения не ломали клиентов/потребителей.
   Смысл один: спека перестаёт быть «бумажной».

2. Property‑based tests для инвариантов (точечно)
   Не обязательно везде, но на узких местах (скидки, сегменты, расчёты, статусы) это мощный инструмент. Он ловит крайние случаи, о которых никто не вспомнил в постановке.
   ИИ хорошо помогает генерировать заготовки таких тестов, если домен детерминирован и типизирован.

3. Executable specifications (BDD/gherkin‑подобное) — только если реально исполняется в CI
   Если BDD превращается в «красивый текст в Confluence», это мёртвая практика.
   Если же сценарий реально исполняется (хотя бы частично) — он становится мостом между бизнесом и проверками.

4. Автогенерация документации вокруг домена
   Минимальный набор, который стоит генерировать/поддерживать как артефакты:
   — Domain glossary: термины, состояния, события, ограничения;
   — Use‑cases catalog: команды/запросы, входы/выходы, ошибки, side‑effects;
   — Examples: пример входа → пример результата (как «живые примеры» для команды и ИИ).

5. Жёсткое правило: генерация привязана к CI
   Документация и спеки должны:
   — генерироваться/проверяться в CI,
   — падать сборкой при рассинхроне,
   — храниться рядом с кодом (docs‑as‑code).
   Иначе всё разойдётся с реальностью и станет токсичным.

В результате получается не «документация ради документации», а контур качества: домен → спека → тесты → CI → домен. И это именно тот контур, который делает ИИ полезным усилителем, а не генератором энтропии.

Далеко не всегда проект стартует с идеально оформленной спеки. Часто проект уже существует, и надо «поднять знание» из кода. Здесь работает подход code‑first документации: строим спецификацию и доки поверх существующей модели.

5. CMS-мир: что будет с клиентскими сайтами на CMS (Bitrix/WordPress/Drupal и т.п.)

Прогноз «CMS умрут» в студийной реальности обычно не подтверждается. CMS остаются и даже усиливаются, просто меняется их роль и цена ошибок.

Почему CMS не исчезнут

1. CMS — это организационная машина для контента. Роли, права, редакторы, медиабиблиотеки, публикации.

2. Большая часть клиентских сайтов — контент + витрина + интеграции «по краю». CMS заточены под «контент → SEO → лиды → итерации».

3. Экосистема — рычаг скорости. Плагины — риск, но и причина time‑to‑market.

Как ИИ усиливает CMS-разработку

ИИ усиливает скорость производства и вариативность:

• генерация шаблонов/компонентов становится повседневностью,

• контент и посадочные клепаются быстрее,

• интеграционная «обвязка» дешевеет,

• появляется шанс держать актуальную карту проекта и документацию.

Главная угроза CMS-мира: плагинность + неявные правила + сложные интеграции

CMS хорошо масштабируют контент, но плохо масштабируют доменные правила, когда те расползаются между:

• настройками модулей,

• шаблонами,

• обработчиками событий,

• интеграционными скриптами.

ИИ ускоряет рост этого «зоопарка», если нет границ.

Эволюция: монолитная CMS → headless/composable → «домен рядом»

Headless — инструмент по показаниям, а не мода. Когда headless оправдан:

• контент нужен, но правила сложные и часто меняются,

• несколько каналов потребления (сайт/ЛК/приложение),

• интеграции критичны,

• надо разделить ответственность между командами.

Практический компромисс: «домен рядом».
CMS остаётся контент‑ядром, а правила и интеграции живут в отдельном слое.

5.5. Легаси на CMS: три уровня боли и разные способы лечения

В студийной реальности большинство проектов — легаси в той или иной степени. Поэтому вопрос «CMS vs фреймворк» часто звучит так: что делать с тем, что уже есть, чтобы оно не дорожало экспоненциально?

Я делю легаси CMS на три уровня.

Уровень 1: контентный легаси.
Контент и шаблоны устарели, структура тяжёлая, SEO сделано «как получится», но правил почти нет, интеграции простые.
Что делать:

• модернизировать тему/шаблоны без вторжения в бизнес‑логику,

• зафиксировать критичные страницы smoke‑регрессией,

• навести порядок в структуре контента, урлах, мета‑тегах.

Уровень 2: легаси с расползшимися правилами.
Акции, сегменты, условия живут в настройках, шаблонах, обработчиках и JS одновременно.
Что делать:

• перестать добавлять новые правила «в настройки» и «в шаблон»,

• выделить единый контур правил (хотя бы модуль/библиотека),

• переносить правила по одному: правило → тест → пример.

Уровень 3: легаси‑интеграционный монолит.
CMS стала центром синхронизаций: CRM, каталоги, фиды, платежи, аналитика. Обновления страшны, отладка тяжёлая, часть интеграций «падает молча».
Что делать:

• применить Strangler Fig для интеграций: вынести их в отдельный интеграционный слой,

• сделать контракты и наблюдаемость обязательными,

• оставить CMS контентом и витриной, а не «мозгом».

5.6. Как преобразовывать легаси CMS под новый подход без переписывания

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

1. Инвентаризация правил (инвариантов). Список «что считается» и «почему так» (10–30 пунктов).

2. Карта источников истины. Где истина по цене/наличию/статусу/сегменту.

3. Контрактная обвязка интеграций. Схема + валидация + логирование + поведение при ошибках.

4. «Домен рядом» сначала в лёгкой форме. Модуль/библиотека внутри репозитория; сервис — по показаниям.

5. Переезд правил по одному. Каждое правило: тест + пример + мониторинг.

6. Орг‑правило: новые важные правила не внедрять в настройки CMS. Важное правило → в доменном контуре.

Приземление: DDD в Bitrix-модулях и интеграциях (и почему это удобный фундамент для AI-генерации)

Если приземлить всё это на контекст, где часть проектов делается на CMS‑уровне (в частности Bitrix), а часть — вокруг интеграций, то разделение Domain / Application / Infrastructure / Interface оказывается не «красивой архитектурой», а способом удерживать проект в состоянии, когда его можно менять без паники.

Что обычно даёт максимальный эффект:

1. Инварианты перестают «протекать» в компоненты и контроллеры
   Компонент/контроллер на Bitrix (или любой другой CMS) становится UI‑слоем: он отображает и собирает ввод, но не решает бизнес‑вопросы.
   Правила остаются в Domain — и начинают быть проверяемыми.

2. Use‑cases становятся единственной точкой оркестрации
   В Application‑слое живут сценарии: «создать заявку», «рассчитать оффер», «применить акцию», «синхронизировать каталог».
   Это убирает хаос, когда один и тот же сценарий реализован «чуть‑чуть по‑разному» в пяти местах.

3. Интеграции уходят в Infrastructure
   Внешние API, очереди, Bitrix‑сущности (инфоблоки/HL‑блоки/ORM), файловые хранилища — всё это инфраструктура.
   Домен не должен знать, как вы читаете данные из Bitrix, он должен знать, что это за данные и какие у них ограничения.

4. Доменные события помогают объяснять поведение без чтения всей кодовой базы
   События уровня LeadCreated, OfferCalculated, PromotionApplied, CatalogSynced превращают поведение системы в понятный журнал смысла.
   Это полезно командам, QA, аналитикам — и полезно ИИ, когда вы строите генерацию тестов, доков и сценариев.

5. Doc/spec/generation строится вокруг use‑case каталога и доменных типов
   Когда use‑cases и доменные типы выражены явно, вы можете генерировать:
   — словарь (термины/состояния/события),
   — каталог сценариев (входы/выходы/ошибки),
   — контракты интеграций,
   — примеры и тест‑скелеты.
   И это начинает работать как фабрика: изменения в правилах автоматически отражаются в проверках и документации через CI.

Смысл в том, что «чистый» доменный контур позволяет Bitrix‑проектам взрослеть: от «CMS‑монолита» к гибридной модели, где CMS остаётся сильной в контенте, а правила и интеграции становятся управляемыми активами.

6. Фреймворки: что будет с клиентскими сайтами на Laravel/Symfony/Node/Next/Nuxt

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

ИИ одновременно:

• снижает цену входа (быстрее собрать «скелет»)

• и повышает цену отсутствия дисциплины (энтропия наступает быстрее).

Где фреймворки выигрывают

1. Там, где у вас есть «правила», а не только «страницы». Инварианты легче держать в одном месте.

2. Там, где интеграции нужно сделать продуктом. Контракты, ретраи, идемпотентность, логирование, очереди.

3. Там, где эксплуатация и наблюдаемость — часть результата. «Почему лиды упали» — не вопрос «потом», это вопрос «сейчас».

ИИ и delivery: быстрее скелеты, выше риск энтропии

ИИ делает дешёвым «нагенерить» много всего. Но сопровождать придётся вам. Поэтому без guardrails скорость превращается в хаос.

✅ Чек‑лист guardrails для ИИ‑ускоренной разработки

Стандарты и границы:

1) структура слоёв и запрет «переливов» зависимостей;
2) правила нейминга и терминов (glossary);
2) единый стиль ошибок (доменные ≠ инфраструктурные ≠ UI).

Контракты и проверки:

4) контрактные тесты для API/интеграций;
5) golden/snapshot‑тесты для критических шаблонов;
6) тесты инвариантов (unit/property‑based там, где имеет смысл).

CI‑ворота:

7) статанализ + форматирование;
8) архитектурные правила зависимостей;
9) генерация/валидация спеки в CI;
10) генерация документации и запрет мержа, если доки отстали.

Операционная устойчивость:

11) observability baseline;
12) security baseline (зависимости, секреты, права, аудит).

6.5. Легаси на фреймворке: типовые симптомы, которые ИИ сделает хуже

У фреймворкового легаси другая природа: не «зоопарк плагинов», а зоопарк способов выразить одно и то же правило.

Симптомы:

• правила размазаны по контроллерам, шаблонам, джобам и интеграциям,

• разные форматы ошибок и результатов,

• интеграции без контрактов («надеемся, что входные данные такие же»),

• тестов мало, регрессия ручная,

• копипаст — основной способ ускорения.

ИИ в этом контексте усиливает хаос: если нет стандартов, он будет генерировать «правдоподобный код», который закрепляет фрагментацию.

6.6. Как преобразовывать фреймворковое легаси без «большого рефакторинга»

Принцип: сначала вводим правила игры для нового кода, затем вытесняем старое «по краю».

1. Ввести архитектурные границы как правило разработки. Новая логика → use‑cases; правила → домен; интеграции → адаптеры; UI без бизнес‑решений.

2. Boy Scout Rule. Любое изменение слегка улучшает ближайшую грязь: вынесли правило, унифицировали ошибку, добавили тест, повесили лог.

3. Стандартизировать ошибки и результаты. Это дешёвый способ снизить энтропию.

4. Тесты инвариантов на самые дорогие правила. 10–20 тестов на деньги/лиды/частые изменения дают больше эффекта, чем «покрыть всё».

5. Наблюдаемость как страховка миграции. Логи и метрики до/после изменений.

6. Strangler Fig для больших зон. Строим новый контур рядом и переводим потоки по одному.

7. CMS vs Framework vs Hybrid: сравнение без религии

Суть выбора — не «что лучше», а какую цену вы будете платить за изменения через 6–18 месяцев.

• CMS: скорость старта и контентная операционка.

• Framework: контроль правил и интеграций при дисциплине.

• Hybrid: контентная скорость + управляемый домен.

Таблица критериев (12 пунктов)

Матч-кейсы выбора

Когда CMS

• контент и SEO — основной двигатель,

• правила простые и редкие,

• клиент реально живёт в редакторе.

Когда Framework

• сайт — система правил и интеграций,

• ошибки дороги,

• нужна наблюдаемость/безопасность/перформанс как часть результата.

Когда Hybrid

• и контент важен, и правила становятся сложными,

• нужен путь эволюции без «переписать всё».

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

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

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

8. Практический план на 12 месяцев для веб-студий и digital-агентств

Управленческая рамка на 5–10 лет

ИИ ускоряет производство кода, поэтому главным дефицитом становится не «написать», а удержать целостность. Целостность удерживают инварианты, контракты и проверяемая модель. Следовательно, инвестиция в доменный слой и автоматические проверки — это инвестиция в пропускную способность команды и безопасность изменений.

Практически это означает: если у студии есть модель, контракты и CI‑ворота, ИИ делает её быстрее и сильнее. Если этого нет — ИИ делает её быстрее… но менее управляемой.

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

8.1. Два параллельных контура: New-Build и Legacy-Improve

В зрелой студии всегда два потока, и их важно не смешивать:

• New‑Build (новые проекты): стандарты с первого дня, быстрый старт, предсказуемая структура.

• Legacy‑Improve (существующие проекты): снижение стоимости изменения правил и регрессии без переписывания.

У них разные KPI. Для легаси KPI — не «сколько задач закрыли», а «насколько дешевле стало менять правила и насколько меньше стало аварий».

8.2. План на 12 месяцев: что именно внедрять и в каком порядке

🔵 Квартал 1 (0–3 месяца): поставить рельсы и зафиксировать базовую предсказуемость

• Старт‑пакет проекта (starter kit).
  Структура репозитория, базовые слои, соглашения, шаблон документации, минимальный набор инструментов качества.

• CI‑ворота как обязательный стандарт.
  Линтер/типизация + базовые тесты инвариантов + проверка контрактов интеграций как «красная кнопка» качества.

• Мини‑глоссарий и use‑cases.
  Небольшой, но обязательный: ключевые термины, 10–20 сценариев, набор ошибок/исключений. Это снижает энтропию ещё до того, как вы «внедряете DDD».

🔵 Квартал 2 (3–6 месяцев): спецификации и контракты как производственные артефакты

• Контракты интеграций как правило: без контракта — не интеграция.
  Выравнивание входов/выходов, ошибок и поведения при сбоях. Это обычно даёт самый быстрый эффект на легаси и на проектах «с интеграциями по краю».

• Docs‑as‑code с проверкой в CI.
  Документация перестаёт «врать» — потому что её актуальность проверяется, а не надеется на дисциплину.

• Шаблон постановок задач «под ИИ».
  Контекст, сценарии, инварианты, примеры, критерии приёмки. Это простое управленческое действие, которое резко повышает качество генерации и снижает «скриптовый зоопарк».

🔵 Квартал 3 (6–9 месяцев): доменный контур и контроль регрессии

• Минимальный домен там, где живут правила.
  Не «DDD везде», а 3–7 сущностей/типов/инвариантов, которые реально влияют на деньги/лиды/конверсию.

• Регрессия по критичным правилам.
  Инварианты + контрактные тесты + немного e2e там, где иначе нельзя поймать поломку (например, лидогенерация, расчёт оффера, ключевые воронки).

• Observability baseline.
  Логирование ключевых событий, корреляция запросов, алерты по сбоям интеграций. Без наблюдаемости легаси‑модернизация превращается в «мы надеемся, что стало лучше».

🔵 Квартал 4 (9–12 месяцев): масштабирование в «фабрику» без потери управляемости

• Внутренние шаблоны и генераторы студии.
  Собственный «framework практик»: стандартизированные заготовки, типовые интеграционные адаптеры, общие проверки, единый стиль ошибок.

• ADR как привычка.
  Коротко фиксируем решения и последствия. Это снижает bus‑factor и упрощает масштабирование команды.

• Метрики как управленческий контур.
  Lead time изменения правила, дефекты на релиз, стоимость регрессии, MTTR, доля покрытых контрактов — чтобы стало видно, что улучшения реально работают.

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

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

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

8.3. Легаси-плейбук: пакет, который можно продавать клиенту

Легаси лучше превращать в продаваемую услугу, а не в «мы будем потихоньку улучшать».

Legacy Stabilization / Legacy Modernization Sprint

1. Аудит правил и источников истины (1–2 недели): список инвариантов, карта данных, карта интеграций.

2. Контракты и наблюдаемость интеграций (1–2 недели): схемы, валидация, логирование, алерты.

3. Минимальный доменный контур для 3–5 ключевых правил (2–4 недели): оффер/акции/сегменты/статусы.

4. Тесты инвариантов + минимальный e2e (1–2 недели): защита от «сломали и не заметили».

5. Docs‑as‑code: карта проекта и инструкция «как менять правила безопасно» (1 неделя).

6. Дорожная карта на 3–6 месяцев: что выносим дальше и почему.

Как не убить бизнес легаси‑рефакторингом

• Не переписывать, а перехватывать потоки (strangler): переносим по одному, старое продолжает работать.

• Каждое вынесенное правило = тест + мониторинг.

• Сначала наблюдаемость, потом оптимизация.

• Запрет на новые быстрые костыли без контракта/стандарта.

• Definition of Done для легаси‑изменений: «перенесли → проверили → наблюдаем».

Метрики именно для легаси

• lead time изменения правила,Метрики именно для легаси

• стоимость регрессии (часы на фиксы после релиза),

• дефекты интеграций и MTTR,

• доля интеграций с контрактами (тренд),

• доля критичных правил с тестами (тренд),

• частота «горячих фиксов».

Минимальный пакет, который окупается почти всегда:
старт‑пакет + контракты интеграций + тесты инвариантов + docs‑as‑code + базовая наблюдаемость.

Этот план не про «идеальную архитектуру» и не про попытку перестроить все проекты под один шаблон. Он про другое: перевести студию в режим предсказуемых изменений, где новые проекты стартуют на рельсах, а легаси постепенно теряет способность генерировать аварии и регрессию.

Если это получается, дальше технологии становятся вторичны: CMS, фреймворк или гибрид — всё работает, пока есть ясная модель, контракты и проверяемость. В горизонте 5–10 лет именно эта связка и будет определять конкурентное преимущество: кто умеет менять правила быстро и безопасно, тот будет выигрывать в мире, где «сделать» становится всё дешевле.

9. Финал: мир 5–10 лет — доменная ясность как конкурентное преимущество

Если собрать всё в одну формулу: ИИ не отменяет инженерную ответственность. Он делает её дороже. Не потому что «станет сложнее код», а потому что скорость производства возрастает, а значит растёт и скорость накопления несогласованности.

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

Что станет главным активом студии/агентства в горизонте 5–10 лет:

1. Ясная модель (пусть минимальная), где правила выражены явно.
   Инварианты живут в доменном контуре, а не в настройках, шаблонах и «кусочках логики».

2. Контракты и исполняемые спецификации.
   Спека — это не документ «для согласования», а часть производственного контура: тесты, моки, SDK, документация, CI‑проверки.

3. Наблюдаемость и проверяемость поведения.
   Чтобы изменения можно было проводить уверенно: видеть последствия, ловить сбои интеграций, отслеживать деградацию конверсии/сценариев.

Что изменится: инструменты вокруг будут всё сильнее автоматизировать генерацию кода/тестов/доков, извлечение спеки из модели и «производственные пайплайны» качества.

Что не изменится: необходимость выбирать границы, проектировать инварианты и отвечать за поведение системы. Это и останется ремеслом — и именно здесь студии смогут удерживать конкурентное преимущество, даже когда «писать код» станет ещё дешевле.