Какой оверхед несет чистая архитектура в скорости написания кода?

Что проверяют

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

Как отвечать

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

• интерфейсы репозиториев: typing.Protocol или abc.ABC плюс реализация на SQLAlchemy, хотя реализация одна;
• несколько моделей вместо одной: доменный dataclass, ORM-модель и Pydantic-схема на входе API, а между ними маппинг туда и обратно;
• use case на каждое действие: отдельный класс или функция, которую вызывает тонкий обработчик;
• сборка зависимостей: передача в конструкторы, Depends в FastAPI или контейнер вроде dependency-injector.

На простой CRUD-операции это легко утраивает число файлов, а новичку нужно время, чтобы понять, куда что класть. Сильнее всего сопротивляется Django: его ORM построен на Active Record, модель там и есть домен, и отрыв от фреймворка лишает админки и ModelSerializer.

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

Где спотыкаются

Отвечают «оверхеда нет, зато потом быстрее». Честнее признать, что первые месяцы разработка идёт медленнее, и объяснить, в какой момент это возвращается.

Путают чистую архитектуру с количеством папок. Каталоги domain, application, infrastructure при импорте SQLAlchemy прямо в домене не дают ничего, кроме лишних файлов.

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