ИИ‑генерация кода: меньше привязки к фреймворкам на старте

Что такое привязка к фреймворку и чем она мешает

Привязка к фреймворку (framework lock-in) — это ситуация, когда ключевая бизнес-логика продукта оказывается «вшита» в конкретный фреймворк: его контроллеры, ORM, систему зависимостей, события, шаблоны, специфичные объекты запроса/ответа. В результате фреймворк перестаёт быть заменяемой деталью — он становится частью домена, хотя по смыслу должен быть лишь инструментом доставки логики в мир HTTP, БД и очередей.

Почему это опаснее всего в первые месяцы

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

Симптомы, что lock-in уже начался

Обычно это выглядит так:

• миграция или даже эксперимент с другим стеком кажется «переписыванием с нуля»;
• везде используются типы и сущности фреймворка (например, модели ORM) как «истинные» доменные объекты;
• бизнес‑правила спрятаны в контроллерах, хуках, middleware, lifecycle-callback’ах;
• простая правка фичи требует трогать десятки файлов «по правилам фреймворка», а не по логике продукта.

Решения, которые фиксируют команду слишком рано

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

Короткий критерий: можно ли заменить фреймворк, не переписывая бизнес‑логику — то есть оставив правила, сценарии и модели, поменяв только внешние адаптеры (HTTP, БД, очередь). Если ответ «нет», lock-in уже мешает развитию.

Почему на старте привязка возникает особенно быстро

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

Давление сроков: «нужно показать демо»

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

Нехватка опыта и вера в «стек по умолчанию»

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

Копипаст из шаблонов и туториалов без понимания границ

Шаблоны стартера и статьи учат «как запустить», но редко объясняют, что именно вы теперь должны фреймворку. Копипаст часто тащит за собой специфичные паттерны (например, активную запись, магические хуки, аннотации), после чего проект уже трудно перенести без переписывания.

Ранний выбор БД/ORM/очередей как источник скрытой зависимости

Самые липкие зависимости появляются не в UI, а в данных и интеграциях. Схема БД под конкретный ORM, транзакции, миграции, способы пагинации, формат событий в очереди — всё это незаметно становится частью бизнес‑логики. Чем раньше эти решения «протекли» внутрь домена, тем дороже будет миграция и тем больше технический долг накопится к моменту роста.

Как ИИ‑генерация кода меняет экономику выбора технологий

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

Важно, что скорость теперь можно получать без «цементирования» архитектуры. Например, в vibe‑coding платформе TakProsto.AI удобно сначала описать домен и сценарии, а затем попросить платформу собрать внешний слой (web/server/mobile) как заменяемые адаптеры: вы быстрее получаете прототип, не превращая фреймворк в центр модели.

Дешевле пробовать несколько реализаций одного требования

ИИ позволяет быстро получить 2–3 варианта одной и той же функции (например, оформление заказа или расписание уведомлений) в разных стилях: «по‑быстрому внутри фреймворка», «через отдельный сервис», «через чистые функции и DTO». Это не про механическое копирование, а про быстрый просмотр архитектурных траекторий и их последствий.

Сравнение по переносимости, а не по популярности

Когда варианты есть на руках, их проще оценивать по критериям переносимости:

• сколько бизнес‑логики живёт вне контроллеров/моделей;
• насколько легко заменить базу данных или очередь;
• где завязки на специфичные аннотации, магию и «особые» типы.

ИИ ускоряет такое сравнение: он может подсветить точки сцепления и предложить альтернативы с меньшим количеством зависимостей.

Автоматизация рутины и «тонкий слой» интеграции

Самое выгодное применение ИИ — генерировать рутинные части: CRUD, обвязку API, сериализацию, валидацию, маппинг. Тогда ручная работа команды концентрируется на домене.

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

Правильная постановка задач ИИ: сначала границы, потом стек

Когда вы просите ИИ «сделай приложение на Django/Next/Spring», вы заранее покупаете привязку: модель данных, структура папок и даже термины в проекте начинают повторять выбранный фреймворк. На ранней стадии это удобно, но потом превращается в «невидимые наручники» — менять стек становится дорого, потому что вместе с транспортом и UI у вас перемешан сам смысл продукта.

Сначала — домен и границы

Лучший запрос к ИИ на старте звучит не как «сгенерируй проект на X», а как «выдели доменную модель и интерфейсы». Начните со сценариев и данных:

• какие сущности существуют (Заказ, Подписка, Пользователь), какие у них правила;
• какие операции важны (создать, отменить, рассчитать цену);
• какие инварианты нельзя нарушать.

Затем попросите ИИ предложить границы модулей: домен, приложение (use cases), инфраструктура (БД, очередь), транспорт (HTTP/CLI). И только после этого — варианты реализации адаптеров под конкретный стек.

Пример формулировки задачи для ИИ

Вместо: «Сделай REST-сервис на FastAPI для заказов»

Попросите:

1. «Опиши доменную модель заказов (сущности, значения, правила) и минимальные интерфейсы репозиториев.»

2. «Опиши use cases и входные/выходные DTO, не привязываясь к HTTP.»

3. «Сгенерируй два адаптера: HTTP‑транспорт и репозиторий для Postgres. Каждый — отдельным модулем, чтобы их можно было заменить.»

Так прототип собирается как набор заменяемых модулей: вы меняете транспорт (например, HTTP → gRPC) или хранилище, не переписывая правила расчёта и сценарии.

Закрепляйте решения короткими ADR

Чтобы ИИ не «расползался» по архитектуре в следующих итерациях, фиксируйте ключевые решения в виде коротких ADR (записей о решениях): что вынесено в домен, где границы, почему выбран такой контракт. Это занимает 10–15 минут, но экономит часы на объяснениях и снижает риск незаметного возврата к фреймворк‑центричному коду.

Архитектурный приём: «домен в центре», фреймворк снаружи

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

1) Доменный слой без импортов фреймворка

В домене остаются сущности, правила, сервисы и сценарии использования (use cases). Важно правило: никаких импортов фреймворка и минимум инфраструктурных деталей.

Например, вместо «контроллер сразу пишет в БД» домен выражает намерение: «сохранить пользователя», «отправить чек», «уведомить».

2) Порты: репозитории, шлюзы, уведомления, платежи

Чтобы домен мог «разговаривать» с внешним миром, вводятся порты (интерфейсы). Это контракт, а не реализация:

• репозитории (доступ к данным);
• шлюзы (внешние API);
• уведомления (email/SMS/push);
• платежи.

ИИ можно использовать, чтобы быстро сгенерировать заготовки портов и аккуратные типы данных/DTO — но сами правила домена должны быть написаны и проверены вами.

3) Адаптеры: отдельные модули для HTTP, БД, очередей, файлов

Всё «фреймворк‑специфичное» живёт снаружи домена:

• HTTP‑адаптер (роуты/контроллеры);
• адаптер БД (ORM/SQL);
• адаптер очередей/фоновых задач;
• файловый адаптер (S3/локальное хранилище).

Полезный приём: пусть ИИ генерирует адаптеры по чётким входам/выходам портов. Тогда при смене, скажем, ORM вы трогаете только модуль адаптера, а не бизнес‑логику.

4) Минимизируем аннотации и декораторы внутри домена

Аннотации, декораторы, «магия» DI‑контейнера и валидация запросов удобны, но тянут зависимости внутрь ядра. В домене лучше оставлять явные вызовы и простые структуры данных, а декораторы — на уровне HTTP‑слоя или инфраструктуры.

5) Проверка: домен запускается в тестах без веб‑сервера

Быстрый тест на отсутствие привязки: доменные сценарии должны выполняться в юнит‑тестах без поднятия веб‑сервера, БД и очередей — с фейковыми реализациями портов.

Если для запуска домена требуется стартовать приложение фреймворка, значит граница размыта и lock‑in уже растёт.

Интерфейсы и адаптеры: где ИИ особенно полезен

ИИ сильнее всего помогает там, где много «рутинного клея»: интерфейсы, контракты данных, адаптеры к внешним системам. Если эту прослойку сделать аккуратно, продукт проще переносить между фреймворками и библиотеками, потому что бизнес‑логика (use cases) не знает, чем именно вы ходите в базу или дергаете платежи.

1) Генерируйте контракты отдельно от реализаций

Попросите ИИ сначала описать порты: интерфейсы репозиториев/клиентов и DTO (контракты данных), не привязываясь к ORM, HTTP‑клиенту или SDK.

Например, UserRepository с методами getById, save, и DTO вроде UserDTO, CreateUserRequest, CreateUserResponse. Важно: контракты должны отражать доменные потребности, а не структуру конкретной таблицы или ответа стороннего API.

2) Две реализации одной абстракции

Попросите ИИ написать две реализации каждого порта:

• «боевую» (например, через ORM/SDK);
• in-memory (для быстрых тестов и прототипа).

Так вы сразу проверяете, что use cases опираются на интерфейс, а не на детали фреймворка. Если in-memory реализацию трудно подставить, значит границы проведены плохо.

3) Один центр маппинга: домен ↔ DTO

Отдельно поручите ИИ создать слой преобразований и держать маппинг в одном месте (например, UserMapper). Это снижает «размазывание» преобразований по контроллерам и репозиториям, которое потом мешает миграции.

4) Проверка переносимости как критерий готовности

Сформулируйте ИИ явное условие: «должно быть возможно заменить ORM/SDK без изменений в use cases». Попросите сгенерировать пример замены: та же логика, другой адаптер. Если замена требует правок в бизнес‑логике — вы уже в lock‑in, просто не заметили.

Подход API-first и контрактное проектирование

API-first — это когда вы сначала фиксируете «что именно умеет система», а уже потом решаете «на чём это поднять». Для ранней стадии продукта это особенно выгодно: вы сохраняете свободу сменить веб‑фреймворк или даже язык, не переписывая бизнес‑логику и не ломая интеграции.

Сначала контракт: ресурсы, поля, ошибки, версии

Начните с описания внешнего поведения: какие ресурсы есть, какие поля обязательны, какие форматы дат/денег используются, какие коды ошибок возвращаются и как выглядит пагинация.

Важно сразу заложить версионирование (например, /v1) и правила обратной совместимости: что можно добавлять без боли, а что считается breaking change. Эта дисциплина снижает риск «случайных» зависимостей от особенностей конкретного фреймворка (например, его сериализации или обработки ошибок).

Как ИИ помогает: спецификация и заглушки

ИИ‑генерация кода полезнее всего на этапе формализации:

1. Попросите ИИ преобразовать описание API в спецификацию OpenAPI: схемы, примеры, ошибки, security.

2. Затем — сгенерировать серверные заглушки (handlers/controllers) и клиентские SDK.

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

Тонкий слой контроллеров — меньше lock-in

Если контроллеры «толстеют» (ORM-запросы, транзакции, правила, формирование DTO), вы быстро попадаете в зависимость от фреймворка и его расширений. Гораздо безопаснее держать это в отдельном слое (use cases / сервисы), а контроллеру оставить роль адаптера.

Контрактные тесты независимо от веб‑фреймворка

Закрепите договор тестами на уровне контракта: проверяйте, что эндпоинты соответствуют OpenAPI (статусы, схемы, заголовки), и что ошибки формируются по правилам. Тогда смена фреймворка превращается в замену адаптера, а не в «переписать всё».

Если нужно, спецификацию удобно хранить рядом с проектом и обсуждать через PR — это дисциплинирует команду и делает изменения API прозрачными.

Тесты как средство от lock-in: генерируем и закрепляем

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

Попросите ИИ сгенерировать тесты, а не «ещё один вариант реализации»

Хороший приём: сначала описать ожидаемое поведение словами (или примерами запрос/ответ), а затем попросить ИИ написать набор тестов. Просите именно модульные и контрактные тесты:

• Модульные: проверяют бизнес‑правила без привязки к веб‑слою.
• Контрактные: проверяют формат входов/выходов API (статусы, поля, коды ошибок).

Чтобы ИИ не «подстроился» под текущий стек, формулируйте задания нейтрально: «проверь, что при неверном email возвращается ошибка валидации X», а не «сделай это через middleware фреймворка Y».

Тесты как страховка при смене фреймворка или библиотеки

Когда придёт время миграции, вы сможете переписать внешний слой (роутинг, ORM, очереди), а затем прогнать тесты и быстро увидеть, что поведение сохранилось. Это снижает риск незаметно изменить продуктовую логику при переносе.

Стабилизируйте поведение: ошибки, валидация, пограничные случаи

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

• коды ошибок и тексты/структуру сообщений;
• валидацию входных данных;
• пограничные значения (0, максимум, пустые списки);
• идемпотентность (повтор одного запроса не ломает данные).

Базовый уровень качества: статический анализ и форматирование

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

Типичные ошибки ИИ‑кода, которые усиливают привязку

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

Красные флаги в сгенерированном коде

Самый частый сигнал — бизнес‑логика уезжает туда, где ей не место.

• Бизнес‑логика в контроллерах/обработчиках запросов: проверки, расчёты, правила скидок, статусы заказов и т.п. живут прямо рядом с HTTP‑слоем. При миграции вы переписываете всё «вместе с роутингом».
• Тесные зависимости от ORM: доменные методы принимают/возвращают ORM‑сущности, а не простые структуры. В результате слой правил знает о ленивых загрузках, транзакциях и аннотациях.

«Магия» вместо явных границ

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

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

Жёсткая привязка к схеме БД без миграционной стратегии

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

• запросы и индексы «зашиты» в бизнес‑правила;
• отсутствуют миграции или они генерируются один раз и забываются;
• нет версии контракта данных (хотя бы на уровне миграций и обратной совместимости).

В итоге любое изменение таблицы превращается в цепочку правок по всему приложению.

Как переписать запрос к ИИ, чтобы получить переносимый вариант

Плохой запрос: «Сгенерируй CRUD для заказов на Framework X с ORM Y».

Лучше задать рамки и потребовать разделение:

«Сгенерируй реализацию функции оформления заказа так, чтобы бизнес‑правила были в отдельном модуле без зависимостей от веб‑фреймворка и ORM. Опиши интерфейсы репозитория и сервиса, DTO/модели домена как простые структуры. Внешний слой (HTTP) и слой хранения сделай адаптерами, которые можно заменить. Добавь примеры тестов на бизнес‑правила без поднятия БД.»

Так вы направляете ИИ не к “магии фреймворка”, а к коду, который легче переносить и развивать.

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

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

Короткий чек‑лист: что должно остаться неизменным при миграции

Если эти элементы описаны и изолированы, вы меняете технологию, а не продукт:

• Доменная модель: сущности, значения, инварианты и бизнес‑правила.
• Публичные контракты: API/события/форматы ошибок (хотя бы на уровне схем).
• Юзкейсы (сценарии): «создать заказ», «начислить комиссию», «отменить подписку» — без привязки к HTTP/ORM.
• Тесты на поведение: что система обязана делать при разных входных данных.
• Правила миграций данных: источники, соответствия полей, ограничения целостности.

План на 1–2 дня: выделить домен, порты, заменить адаптеры

1. Выпишите 5–10 ключевых сценариев и оформите их как функции/классы уровня приложения.

2. Определите «порты» (интерфейсы) на границе: репозитории, очередь, платежи, отправка писем, внешний API.

3. Переместите доменную логику внутрь: ей нельзя «знать» про контроллеры, ORM и конкретные типы фреймворка.

4. Вынесите текущую инфраструктуру в адаптеры: один адаптер на одну внешнюю технологию.

ИИ здесь ускоряет рутину: по вашему описанию он может сгенерировать заготовки интерфейсов, каркасы модулей, прокинуть зависимости и создать минимальные тестовые заглушки.

Стратегия «двойного запуска»: старый и новый адаптер параллельно

Чтобы не делать «большой взрыв», добавьте второй адаптер рядом с текущим (например, новый репозиторий или новый HTTP‑клиент) и переключайте выбор через конфигурацию/фичефлаг.

Практика: сначала запускайте «двойную запись» (старый + новый), затем сравнивайте чтение, и только потом переключайте основной путь. ИИ можно попросить:

• сгенерировать обвязку для фичефлага;
• написать сравнение результатов и логирование расхождений;
• подготовить временные метрики/алерты.

Миграции данных: как подготовить слой репозиториев и скрипты

Подготовьте миграцию как отдельный продуктовый артефакт:

• Единый слой репозиториев с методами уровня домена (не «табличные CRUD»).
• Скрипты переноса идемпотентные: их можно запускать повторно без порчи данных.
• Проверки: количество записей, контрольные суммы, выборочная сверка бизнес‑инвариантов.

ИИ полезен для генерации шаблонов миграционных скриптов, маппинга полей и тестов на корректность переноса — но обязательно задавайте входные/выходные форматы и ограничения (что нельзя менять в данных).

Как использовать ИИ для автоматизации рутинной части переноса

Давайте ИИ не абстрактное «перепиши на X», а пакет задач:

• «Создай новый адаптер, реализующий порт Repository, без изменения доменных типов».
• «Сгенерируй тесты на сценарии A/B/C по таким входам и ожидаемым результатам».
• «Напиши миграционный скрипт по этой схеме и добавь проверки целостности».

Так вы переносите систему частями, контролируя риски и сохраняя неизменным главное — поведение продукта.

Компромиссы: когда привязка допустима и как её контролировать

Привязка к фреймворку (или поставщику) не всегда зло. На ранней стадии продукта иногда выгоднее сознательно «заплатить» lock‑in ради скорости, понятных шаблонов и меньшего количества решений. Проблема начинается, когда привязка возникает случайно и расползается по проекту.

Когда lock-in можно принять осознанно

Имеет смысл соглашаться на привязку, если она ускоряет проверку гипотезы и снижает вероятность не выпустить продукт вообще. Например: готовая админка, стандартный ORM, типовой UI‑kit, «батарейки в комплекте» для аутентификации. Здесь ИИ помогает быстро собрать каркас, но важно сразу определить: это временная опора или стратегический выбор.

Где без привязки не обойтись

Полностью «без привязки» не бывает: хостинг/облако, почтовые провайдеры, платежи, аналитика, очереди, CDN — всё это внешние зависимости. Задача не в том, чтобы их избегать, а в том, чтобы не размазывать детали интеграции по доменной логике.

Как оценивать стоимость выхода

Оценка выхода — это не только часы разработки. Смотрите на:

• Время: сколько модулей затронет замена, сколько нужно тестов/миграций.
• Риски: простои, потери данных, регрессии в критичных сценариях.
• Компетенции: есть ли в команде опыт альтернативного стека, сколько времени на обучение.

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

Правило контроля: фиксируем точки привязки

Договоритесь: у каждой зависимости есть «точка привязки» — один модуль/пакет, где живёт интеграция. Всё остальное общается с ней через интерфейс. ИИ особенно полезен, чтобы быстро сгенерировать адаптеры и заглушки, а затем закрепить поведение тестами. Так lock‑in остаётся управляемым: вы знаете, что именно придётся менять, когда придёт время.

Итоги и чек‑лист действий на ранней стадии

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

Если вы работаете в российском контуре и хотите ускорять прототипирование без потери управляемости, TakProsto.AI может быть удобным вариантом: платформа помогает собирать приложения через чат, поддерживает планирование (planning mode), снапшоты и откат, экспорт исходников и раздельную генерацию фронтенда (React), бэкенда (Go + PostgreSQL) и мобильных клиентов (Flutter). Это хорошо сочетается с подходом «домен в центре»: домен фиксируете вы, а внешние адаптеры можно быстро пересобирать.

Краткое резюме: 5 практик, которые дают свободу выбора

1. Домен и правила — отдельно от инфраструктуры: бизнес‑логика живёт в чистых модулях, без импортов веб‑фреймворка/ORM.

2. Контракты раньше реализации (API-first): сначала схемы запросов/ответов и события, потом контроллеры и хранилища.

3. Интерфейсы на границах: репозитории, очереди, внешние API описаны интерфейсами; реализации — адаптеры.

4. Тесты фиксируют поведение, а не технологию: больше контрактных и доменных тестов, меньше тестов «как устроен фреймворк».

5. ИИ используют как ускоритель шаблонов: генерируем каркас (адаптеры, маппинг, валидаторы), но правила и зависимости утверждаем заранее.

Мини‑чек‑лист для команды на неделю старта

• День 1: сформулировать 3–7 ключевых сценариев (use cases) и сущности домена; описать входы/выходы.
• День 2: зафиксировать границы модулей и список внешних зависимостей (БД, очереди, платёжка).
• День 3: сделать контракты API/событий и договориться о версиях.
• День 4: сгенерировать ИИ каркас: контроллеры/хендлеры + адаптеры + заглушки интерфейсов.
• День 5: написать базовые доменные и контрактные тесты; подключить CI.
• День 6–7: закрыть «вертикальный срез» (1 сценарий end‑to‑end) и измерить, где фреймворк уже просочился в домен.

Какие артефакты хранить в репозитории: контракты, тесты, ADR

Храните то, что переживёт смену стека:

• Контракты: OpenAPI/JSON Schema/AsyncAPI, примеры payload’ов, правила версионирования.
• Тесты: доменные (use case), контрактные (API), минимальный набор интеграционных.
• ADR (Architecture Decision Records): короткие решения «почему так», дата, альтернативы, условия пересмотра.

Идеи для следующих шагов

• Провести аудит: где домен зависит от фреймворка (импорты, аннотации, базовые классы).
• Рефакторить адаптеры: вынести преобразования данных, спрятать детали ORM/SDK.
• Усилить тесты: добавить негативные кейсы и «золотые» примеры контрактов, чтобы миграция не ломала поведение.