Ловушка
Clean Architecture одна из самых переоценённых вещей на старте. И одна из самых недооценённых на дистанции. Проблема в том, что её либо боготворят, либо полностью игнорируют. Оба варианта ошибка. Я видел проекты, где маленькая команда на простом продукте строила полноценный DDD с Clean Architecture, кучей слоёв и интерфейсов. В итоге: разработка медленная, не все понимают структуру, порог входа высокий. И главный вопрос - зачем?

MVP не нуждается в Clean
Если у тебя стартап на 1–2 человека и ты пишешь MVP, тебе не нужен Clean Architecture. Вообще. Твоя задача на этом этапе: быстро проверить гипотезу, выкатить фичи, понять, есть ли вообще продукт. В этом контексте слои, DTO, интерфейсы, разделение домена это просто замедление.
Многие пытаются «сделать сразу правильно, чтобы потом не переделывать». Звучит логично. На практике — нет. Ты не знаешь, каким будет продукт, где будет нагрузка и что вообще останется. И начинаешь проектировать под будущее, которого ещё нет.
Где Clean реально нужен
Clean Architecture нужен тогда, когда продукт растёт, появляется команда, начинается текучка, и код живёт долго. В этом сценарии он даёт предсказуемую структуру, быстрый онбординг и управляемость изменений. Простой ориентир: если новый разработчик за 1–2 недели вкатывается в проект — архитектура работает. Если нет — ты просто усложнил.
Есть и обратная крайность: «нам не нужен Clean вообще» — и продолжают расти. Тогда начинаются реальные проблемы: код разрастается, зависимости переплетаются, изменения становятся дорогими. В какой-то момент приходится переписывать.

Эволюция, а не религия
Правильный подход — эволюция. Сначала простой код, быстрый MVP. Потом появляется понимание, узкие места, и только тогда вводится структура. Clean Architecture — это не «включить флаг». Ты не обязан делать всё сразу: домен, DTO, мапперы, репозитории. Ты приходишь к этому, когда появляется реальная необходимость.
И да, тесты лучше писать сразу, они позволяют безопасно менять код и постепенно вводить структуру. Главный вопрос всегда один: это сейчас ускоряет разработку или замедляет? Зрелость разработчика это не «всегда делать правильно». Это понимать, когда именно это нужно.