В статье разбирается «MVVM-курильщика»: когда ViewModel разрастается до «помойки» на тысячи строк и тянет на себя логику, навигацию и даже форматирование. Главный вывод — MVVM работает лучше, когда ViewModel управляет явным состоянием и потоком событий, а не собирает всё подряд.Утверждается, что проблемы MVVM чаще начинаются с неверного понимания ответственности: ViewModel воспринимается как «место, куда кладу всё, что не влезло во View».В качестве причин называются: нарушение инкапсуляции (вплоть до UI-зависимостей во ViewModel), отсутствие чёткого State и противоречивые @Published-переменные, а также логика навигации внутри ViewModel.Вместо двустороннего связывания как «по умолчанию» описывается подход Unidirectional Data Flow (однонаправленный поток данных): View отправляет Action, ViewModel обновляет State, View рендерит State.Предлагается мыслить ViewModel как «машину состояний» и хранить единый State (например enum) со сценариями вроде idle/loading/loaded/error.Побочные эффекты (сеть, аналитика, навигация) предлагается отделять через абстракции/протоколы; навигацию — через Coordinator, а тесты строить без создания UIKit/SwiftUI-объектов.Почему это важно: Когда ViewModel превращается в «свалку», цена поддержки растёт быстрее функциональности: сложнее предсказать поведение экрана и локализовать регрессии. Переход к явному состоянию и однонаправленному потоку обычно означает меньше невалидных сочетаний состояния и более понятную причинно-следственную связь событий. Это напрямую влияет на тестируемость и скорость изменений.На что обратить внимание: В тексте подчеркивается, что архитектура описывает управление сложностью и состоянием, а не раскладку файлов. Вопросы сводятся к тому, где проходит граница ответственности ViewModel: что считается данными и состоянием, а что — представлением, навигацией и побочными эффектами. Следующий шаг, который подразумевается, — разнести эти роли по отдельным абстракциям и проверить, что сценарии состояния можно перечислить и тестировать.