Хотел написать обзор про архитектуру. Плюнул.
Хотел сделать обзорный пост про подходы к структуре проекта и организации разработки. Clean Architecture, feature-first, DDD, TDD — всё как положено: суть, плюсы, минусы, что почитать.

Набросал драфт. Почитал. Плюнул.

Куча мутных слов и абстракций — и очень мало толку для реальной жизни. И пока пытался свести это в нормальный текст, понял, почему мне самому это не заходит.

Сформулирую.

Проблема первая. Эти концепции выросли не из нашего мира.
Clean Architecture, DDD — это мир больших, долгоживущих серверных систем. Сложный бизнес-домен, команды в десятки человек, горизонт жизни проекта — годы. Там эти подходы решают реальную боль.

Flutter-приложение — чаще всего другое. Тоньше домен, меньше команда, короче цикл. И когда концепция из одного мира переносится в другой, она переносится с трением: формально слои есть, а боль, ради которой они придумывались, — отсутствует. Остаётся ритуал без причины.

Проблема вторая. Все они продаются как ультимативное решение какой-то глобальной проблемы.
А в реальности глобальной проблемы нет. Есть совокупность требований и кодовая база, в которой важно не запутаться. Всё.

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

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

Тут важно не уйти в другую крайность. Я не говорю «архитектура не нужна» — без неё проект тоже превращается в кашу, просто быстрее. Я говорю про другое: знание названий подходов и умение выстроить удобную кодовую базу — это разные навыки. Первое часто выдают за второе.

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

Сейчас код пишется условно мгновенно и условно бесплатно. И вся экономика, на которой стояли эти подходы, поехала.

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

И вот в этих задачах Clean, DDD, TDD не помогают примерно никак. Они про то, как разложить код — а не про то, как понять, какой код вообще нужен.
Поэтому драфт обзорного поста отправился в корзину. Думаю, дальше интереснее говорить не про то, как нарезать папки, а про то, как в новых условиях проектировать фичи. Этим и займусь.