Когда рассказывают про архитектуру Flutter-приложения, всё обычно выглядит слишком аккуратно.

Есть Bloc, есть Dio, есть go_router, есть get_it. Где-то рядом лежат репозитории, модели, пара экранов и слайд со стрелками. На демо это звучит убедительно: “вот UI-слой, вот data-слой, вот state management”. Кажется, что если взять правильный набор пакетов, дальше система почти сама соберётся.

У меня так не вышло.

Я делаю Flutter-приложение для изучения языков. Это не pet-проект на три экрана, а полноценный клиент: авторизация через несколько провайдеров, анонимный вход, перевод, распознавание, генерация контента, учебные капсулы, локальные настройки, офлайн-поведение, WebSocket-события, длинные фоновые операции. И основные проблемы там начинаются не на уровне Flutter, а в тот момент, когда продуктовая логика перестаёт помещаться в учебные примеры.

Почти все полезные инженерные решения в проекте появились не из любви к “красивой архитектуре”, а после вполне приземлённых сбоев в реальных сценариях:

пользователь зашёл анонимно, потом решил зарегистрироваться и не должен потерять данные;

сеть на телефоне формально есть, но realtime-слой умер;

тяжёлая серверная операция крутится десятки секунд, а UI не должен выглядеть подвисшим;

приложение надо уметь не просто логинить, а аккуратно переживать смену identity;

после logout нельзя надеяться, что десяток старых Cubit-ов сами как-нибудь очистятся.

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