Архитектура мобильного приложения: как перейти от экранов к продуманной структуре

Когда я только начинал писать мобильные приложения, подход был очень прямолинейный: открыл IDE, создал экран, добавил обработчики нажатий, положил немного логики в Activity, Fragment или ViewController — и вроде бы всё работает. На первых двух-трёх экранах такая схема действительно кажется удобной. Но дальше начинается то, с чем сталкивается почти каждый разработчик: появляется ещё одна бизнес-правила, ещё один запрос к API, ещё один способ отобразить данные, и код перестаёт быть прозрачным.

Логика смешивается с интерфейсом, доступ к данным расползается по приложению, тесты либо не пишутся вовсе, либо оказываются слишком дорогими в поддержке, а любая новая фича превращается в рискованный мини-рефакторинг. В какой-то момент становится ясно: проблема не в языке, не в SDK и не в конкретном фреймворке. Проблема в том, как организован код.

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

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

Почему архитектура мобильного приложения — это не опция, а необходимость

Если убрать теорию и говорить честно, архитектура нужна потому, что мобильное приложение почти никогда не бывает «завершённым» в момент первого релиза. Это живой продукт. В нём появляются новые фичи, меняются API, пересматриваются бизнес-требования, исправляются дефекты, добавляется аналитика, пуш-уведомления, офлайн-режим, кэширование, локализация, оптимизация производительности.

Когда архитектуры нет или она продумана плохо, любое изменение становится потенциально опасным. Разработчик не уверен, что локальная правка не сломает соседний сценарий. Тест на новую бизнес-логику написать сложно, потому что она завязана на UI или жизненный цикл платформы. Команда не может эффективно работать параллельно, потому что ключевые зависимости стянуты в несколько перегруженных классов.

На практике хорошая архитектура даёт не «красоту» кода, а инженерную устойчивость продукта. Это особенно заметно в долгоживущих проектах, где стоимость поддержки постепенно начинает превышать стоимость первой реализации.

Вот что даёт правильная архитектура:

• Разделение ответственности — каждая часть кода занимается своей задачей и не пытается решать всё сразу
• Тестируемость — бизнес-логику можно покрывать unit-тестами без запуска UI и без поднятия половины приложения
• Масштабируемость — новые функции добавляются поверх существующей структуры, а не через её разрушение
• Командная разработка — разработчики могут параллельно работать с разными слоями и модулями без постоянных конфликтов
• Поддерживаемость — через полгода код остаётся читаемым, а не превращается в археологию из случайных решений

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

От экранов к слоям: как переструктурировать мышление

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

Но проблема в том, что реальная логика продукта живёт не в самих экранах. Она живёт в правилах валидации, в координации сетевых запросов, в обработке ошибок, в кэшировании, в преобразовании данных, в авторизации, в работе с локальным хранилищем, в политике ретраев, в синхронизации состояний. Если всё это складывать рядом с UI, экран быстро становится точкой хаоса.

Более зрелый способ мыслить приложением — видеть в нём не только экраны, а слои ответственности.

Каждый слой отвечает за свою область:

• UI Layer отвечает за отображение и обработку пользовательского ввода
• Presentation Layer управляет состоянием экрана и преобразованием данных для отображения
• Domain Layer содержит бизнес-правила, которые не зависят от платформы
• Data Layer работает с источниками данных: API, базы данных, кэши

Ключевая идея здесь не в формальном делении папок, а в направлении зависимостей. UI не должен знать, как именно устроен API-клиент. Domain не должен зависеть от конкретного экрана, фреймворка или визуального компонента. Data-слой не должен диктовать бизнес-правила. Когда слои связаны через понятные интерфейсы, код становится заменяемым и предсказуемым.

Это особенно важно в реальных сценариях разработки. Например, сегодня данные приходят из REST API, завтра часть логики переезжает в GraphQL, послезавтра появляется локальный кэш или offline-first поведение. Если границы слоёв выдержаны, такие изменения затрагивают локальные участки системы, а не приложение целиком. С точки зрения поддержки это критично.

Практические архитектурные паттерны для мобильной разработки

Теория полезна, но в продакшене всегда нужен ответ на более прикладной вопрос: какой паттерн выбрать и почему. Ниже — подходы, которые действительно встречаются в мобильной разработке и работают при разумном использовании.

MVC (Model-View-Controller) — и почему его недостаточно

MVC — один из самых старых и самых известных паттернов. Его базовая идея проста: разделить код на Model, View и Controller. На уровне концепции всё выглядит аккуратно: данные отдельно, отображение отдельно, логика отдельно.

Но на мобильных платформах классическая схема MVC почти всегда быстро размывается. На практике Activity, Fragment или ViewController начинает одновременно управлять UI, обрабатывать пользовательские события, вызывать сетевые операции, валидировать входные данные и принимать решения по навигации. Формально это всё ещё может называться MVC, но фактически получается перегруженный координирующий объект.

Именно так появляются так называемые God Object — классы, которые знают слишком много и делают слишком многое. Их сложно тестировать, они неудобны для code review, а любое изменение в них несёт высокий риск регрессии.

MVC работает в веб-приложениях, но на мобильных платформах нужны более специализированные подходы.

С инженерной точки зрения главный недостаток MVC в мобильной разработке — слабый контроль над тем, куда утекает логика. Паттерн сам по себе не даёт достаточных ограничений, а значит, команда быстро начинает писать «как удобно сейчас», а не «как будет поддерживаться потом».

MVP (Model-View-Presenter) — разделение логики UI

MVP появился как попытка вынести UI-логику из перегруженного контроллера. В этой модели View остаётся более пассивным, а Presenter берёт на себя реакцию на действия пользователя, подготовку данных и управление состоянием отображения.

Это уже заметно лучше с точки зрения тестируемости. Presenter можно проверять unit-тестами без поднятия реального UI. Для команд, которые делают ставку на явные интерфейсы и хотят строго контролировать контракты между слоями, MVP по-прежнему может быть рабочим инструментом.

Но в мобильной среде у MVP есть и слабые места. Presenter обычно связан с View через интерфейс, и если жизненный цикл экрана учтён плохо, появляются риски утечек памяти, висячих ссылок и некорректной работы после пересоздания экрана. Кроме того, при росте проекта Presenter нередко начинает разрастаться почти так же, как раньше разрастался Controller.

Иными словами, MVP решает часть проблем, но требует дисциплины. Без неё легко получить не чистую архитектуру, а просто новый тип перегруженных классов.

MVVM (Model-View-ViewModel) — состояние и реактивность

MVVM хорошо совпадает с тем, как устроены современные мобильные фреймворки и подходы к реактивному UI. Центральная идея здесь в том, что ViewModel владеет состоянием экрана и публикует его, а View только подписывается на изменения и отображает их.

Это очень практичная модель. Она уменьшает количество логики в UI-слое, делает потоки данных более прозрачными и хорошо сочетается с современными инструментами вроде Kotlin Coroutines, Flow, LiveData, SwiftUI и Combine.

Преимущества MVVM:

• ViewModel не зависит от UI и не привязана к жизненному циклу Activity
• State Management встроен в паттерн
• Легко писать тесты для ViewModel
• Хорошо работает с Kotlin Coroutines и Flow

На практике это один из самых удобных стартовых вариантов для нового проекта. Он достаточно простой, чтобы команда не утонула в шаблонном коде, и достаточно сильный, чтобы выдерживать рост приложения.

На практике я рекомендую MVVM как стартовый паттерн для новых проектов.

Но здесь тоже есть важная оговорка: MVVM не спасает автоматически. Если ViewModel начинает напрямую работать с API, собирать аналитику, принимать бизнес-решения, управлять навигацией и хранить временное состояние десятка сценариев, она так же легко превращается в новый «центр тяжести». Поэтому MVVM хорош именно в сочетании с нормальным разделением слоёв и ответственностей.

Clean Architecture — когда приложение становится сложным

Clean Architecture — это скорее набор принципов организации системы, чем один конкретный паттерн. Её основная идея в том, чтобы разделить приложение на независимые слои с ясными правилами зависимости: внешние детали не должны определять внутреннюю бизнес-логику.

В мобильной разработке это обычно означает, что бизнес-правила и use case-логика изолируются от фреймворка, UI и способов хранения данных. API можно заменить, базу — переехать, экран — переписать, а core-логика при этом остаётся стабильной.

Пример такого подхода обычно выглядит так: UI взаимодействует с Presentation-слоем, тот вызывает Use Cases, те работают через Repository-интерфейсы, а конкретные реализации репозиториев живут уже в Data-слое и знают про сеть, БД и кэш.

Clean Architecture действительно даёт высокую гибкость и отличную тестируемость. Но у этого есть цена: больше абстракций, больше интерфейсов, больше кода, выше требования к дисциплине команды. Если проект маленький, такая структура может замедлять разработку и создавать ложную сложность там, где её пока нет.

Именно поэтому применять её стоит осознанно.

Clean Architecture даёт максимальную гибкость, но требует больше кода. Используйте её, когда приложение становится достаточно сложным, чтобы оправдать эту сложность.

Из практики: самый частый антипаттерн здесь — механически копировать «чистую архитектуру» из чужого шаблона без понимания, какие реальные проблемы она должна решить. Архитектура полезна только тогда, когда снижает связанность и стоимость изменений, а не когда просто увеличивает число директорий в проекте.

Ключевые компоненты архитектуры мобильного приложения

1. Управление состоянием (State Management)

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

Одна из самых частых причин трудноуловимых багов в мобильных приложениях — состояние, размазанное по нескольким объектам. Часть хранится в UI, часть во ViewModel, часть в адаптере, часть в кэше, часть приходит асинхронно из нескольких источников. В результате приложение может попасть в противоречивую конфигурацию, которую сложно воспроизвести и ещё сложнее отладить.

Правило: состояние должно быть единым источником истины.

Когда есть один центр управления состоянием, становится гораздо проще отслеживать переходы между состояниями, писать тесты на сценарии и избегать ситуаций, где одновременно существуют, например, loading = true и уже загруженный список пользователей. Такая несогласованность — типичный симптом слабой архитектуры.

С практической точки зрения полезно моделировать состояние явно: через sealed class, immutable state object или похожие конструкции. Это улучшает читаемость, снижает количество неявных переходов и хорошо работает в связке с реактивным UI. Кроме того, явная модель состояния отлично помогает в code review: сразу видно, какие сценарии приложение поддерживает, а какие ещё не учтены.

2. Зависимости и внедрение (Dependency Injection)

Любой нетривиальный класс зависит от других объектов: API-клиента, репозитория, логгера, валидатора, навигатора, менеджера авторизации. Если создавать эти зависимости прямо внутри класса, он быстро теряет гибкость и тестируемость.

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

Такой подход позволяет:

• Легко подменять реальные объекты на тестовые (mock’и)
• Переиспользовать один объект в разных местах
• Централизованно управлять созданием объектов

Для внедрения зависимостей используйте фреймворки вроде Hilt (для Android) или Koin (для Kotlin Multiplatform).

Из практики: сам DI-фреймворк — это не архитектура, а инфраструктурный инструмент. Он помогает удобно собирать граф зависимостей, но не заменяет решение о границах модулей и слоях. Если зависимости плохие по смыслу, Hilt или Koin это не исправят. Поэтому сначала стоит проектировать контракты между частями системы, а уже затем автоматизировать их создание.

3. Обработка ошибок и исключений

Обработка ошибок должна быть частью архитектуры, а не добавлена постфактум.

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

Хорошая практика — не прокидывать сырые исключения бесконтрольно через все слои, а преобразовывать их в понятные доменные или presentation-модели ошибок. Тогда UI получает не абстрактное исключение, а конкретное состояние: например, ошибка сети, ошибка валидации, отсутствие доступа или временная недоступность сервиса.

Это делает поведение приложения более предсказуемым, а код — более поддерживаемым. Плюс тестировать такой сценарий существенно проще, чем ловить разрозненные try/catch по всему проекту.

4. Асинхронность и параллелизм

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

Используйте современные инструменты:

Для Android:

• Kotlin Coroutines с Flow для реактивного программирования
• LiveData для управления состоянием в UI

Для iOS:

• Async/await (Swift 5.5+)
• Combine для реактивного программирования

Но важно не только выбрать правильные инструменты, но и договориться о правилах их использования. Например, где именно переключаются диспетчеры, кто отвечает за отмену операций, как обрабатываются конкурентные запросы, допустимы ли параллельные обновления одного и того же состояния. Большинство проблем с асинхронностью возникает не из-за отсутствия библиотек, а из-за отсутствия единых соглашений.

Если в проекте эти правила не формализованы, баги будут появляться в самых дорогих для отладки местах: гонки состояний, дублирующиеся запросы, потерянные обновления и «мигающий» UI.

Практический процесс построения архитектуры

Теория полезна, но архитектура становится ценной только тогда, когда её можно применять пошагово в реальном проекте. Ниже — практическая последовательность, которая хорошо работает и для новых приложений, и для постепенного наведения порядка в существующем коде.

Шаг 1: Определите границы модулей

Сначала разделите приложение на логические части:

• auth — аутентификация и авторизация
• users — работа с пользователями
• posts — работа с постами
• core — общие компоненты (сетевые запросы, логирование, etc.)

Каждый модуль должен быть независимым. Модуль auth не должен знать о модуле posts.

Это правило кажется очевидным, но именно на нём чаще всего и ломается масштабирование. Если модули начинают напрямую тащить друг у друга реализации, общие модели и случайные утилиты, проект быстро превращается в связанную монолитную структуру, где формальное деление на пакеты уже ничего не даёт.

Хороший модуль — это не просто папка, а ограниченный контекст с понятной ответственностью. Чем лучше определены границы, тем легче поддерживать сборку, тестировать изолированные части и распределять задачи между разработчиками.

Шаг 2: Определите точки входа

Каждый модуль должен иметь чёткий API — набор интерфейсов, через которые другие модули с ним общаются.

Это похоже на контракт между частями системы. Внешний код должен знать, что умеет модуль, но не обязан знать, как именно это реализовано. Такой подход снижает связанность и позволяет безопаснее рефакторить внутренности модуля без каскадных изменений во всём проекте.

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

Шаг 3: Используйте паттерны для решения конкретных проблем

Одна из самых зрелых инженерных привычек — не применять архитектурные решения «на всякий случай». Паттерны должны решать реальные проблемы проекта, а не использоваться ради соответствия модной схеме.

Не пытайтесь применить всю Clean Architecture сразу. Начните с простого:

1. Отделите логику от UI — используйте ViewModel
2. Централизуйте управление состоянием — используйте State Object
3. Внедряйте зависимости — используйте DI фреймворк
4. Разделите на слои — когда приложение растёт

Такой путь хорош тем, что позволяет наращивать архитектуру постепенно, сохраняя темп разработки. Это особенно важно для продуктовых команд, где сроки релизов и обратная связь от пользователей часто важнее идеальной схемы на старте.

Если архитектурный слой не даёт выигрыша в читаемости, тестируемости или изоляции изменений, возможно, он добавлен слишком рано.

Шаг 4: Тестируйте архитектуру

Хорошая архитектура должна быть тестируемой. Напишите тесты для каждого слоя.

Это не декоративное требование, а практическая проверка качества структуры. Если слой трудно протестировать изолированно, значит, он, скорее всего, слишком сильно связан с внешними деталями или делает слишком много сразу.

В мобильных проектах минимально разумный уровень — unit-тесты для ViewModel, Presenter, Use Cases и ключевой бизнес-логики. Интеграционные тесты полезны для проверки связки репозиториев, API и локального хранилища. А UI-тесты стоит оставлять для критических пользовательских сценариев, потому что они медленнее, дороже в сопровождении и хуже подходят для частой обратной связи в CI.

С инженерной точки зрения тесты помогают не только ловить регрессии, но и держат архитектуру в форме. Код, который невозможно удобно тестировать, почти всегда сигнализирует о проблеме в проектировании.

Таблица: выбор паттерна по сложности проекта

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

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

Частые ошибки в архитектуре мобильных приложений

Ошибка 1: Переинженеринг с самого начала

Самая частая ошибка — применять Clean Architecture к приложению с двумя экранами. Это приводит к излишней сложности кода и замедлению разработки.

Проблема здесь не в самой Clean Architecture, а в несоответствии инструмента задаче. Когда для простой формы авторизации создаются use case, несколько слоёв абстракций, фабрики, мапперы и десятки интерфейсов, команда начинает тратить время на обслуживание структуры, которая пока не даёт пользы.

Решение: начните с простого (MVVM), добавляйте слои, когда приложение растёт.

Хорошая архитектура эволюционирует вместе с проектом. Это нормальный путь, а не признак «недостаточно правильной» разработки.

Ошибка 2: Утечки памяти через контекст

Одна из классических проблем мобильной разработки — долгоживущие объекты, которые случайно удерживают ссылку на Activity, Fragment, ViewController или другой объект, связанный с жизненным циклом экрана. В результате экран уже должен быть уничтожен, а память всё ещё занята.

Такие ошибки особенно часто возникают, когда контекст передают в репозитории, singleton-объекты, менеджеры или фоновые задачи без необходимости. Снаружи это выглядит как случайные просадки производительности, нестабильность и трудновоспроизводимые баги.

Практический вывод простой: зависимости, связанные с UI-контекстом, нужно ограничивать по области жизни, а бизнес-логику и состояние выносить туда, где они не завязаны на экран напрямую. Это одна из причин, почему ViewModel и корректная работа с lifecycle-компонентами настолько важны.

Ошибка 3: Блокирующие операции на главном потоке

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

Это не просто техническая неточность, а архитектурная проблема: значит, в проекте не определены правила работы с асинхронностью и разделением ответственности между слоями.

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

Ошибка 4: Слишком много логики в Activity/Fragment

Это, пожалуй, самый узнаваемый симптом незрелой структуры проекта. Activity или Fragment начинает делать всё сразу: и инициализировать UI, и вызывать API, и валидировать поля, и преобразовывать модели, и решать, когда показывать loader, и управлять навигацией.

Такой код быстро становится хрупким. Его трудно читать, трудно тестировать и почти невозможно безопасно рефакторить без риска затронуть несколько сценариев разом.

На практике UI-классы должны оставаться максимально тонкими: подписываться на состояние, рендерить интерфейс, делегировать действия пользователя в Presentation-слой. Всё, что можно вынести из них без потери ясности, обычно стоит вынести.

Ошибка 5: Игнорирование жизненного цикла

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

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

С инженерной точки зрения это тот случай, когда «работает на моём устройстве» ничего не значит. Архитектура должна быть устойчива не в одном идеальном сценарии, а в нормальной хаотичной среде реального использования.

Чек-лист архитектуры для нового проекта

Перед тем как начать разработку, проверьте:

• [ ] Определены модули — приложение разделено на логические части
• [ ] Выбран паттерн — MVVM, Clean Architecture или другой, в зависимости от сложности
• [ ] Настроено управление состоянием — есть единый источник истины для данных
• [ ] Настроено внедрение зависимостей — используется DI фреймворк
• [ ] Определены точки входа — каждый модуль имеет чёткий API
• [ ] Настроена обработка ошибок — есть стратегия для разных типов ошибок
• [ ] Есть слой данных — API, база данных, кэш отделены от UI
• [ ] Есть тесты — хотя бы unit-тесты для ViewModel и Use Cases
• [ ] Документирована архитектура — есть README с описанием структуры
• [ ] Настроен CI/CD — тесты запускаются автоматически при каждом commit

Этот список полезен не только как стартовая проверка, но и как инструмент технического ревью в начале проекта. Если хотя бы по нескольким пунктам у команды нет ясного ответа, это почти всегда означает, что проблемы проявятся позже — уже в момент ускорения разработки, подключения новых участников или подготовки релиза.

Особенно недооценивают обычно два пункта: документацию и CI/CD. Без краткого описания архитектуры даже хороший проект сложно быстро понять новому разработчику. А без автоматического запуска тестов и базовых проверок качество структуры быстро деградирует просто потому, что у команды нет постоянной обратной связи.

FAQ

В: Какой паттерн выбрать для начинающего разработчика?

О: MVVM с LiveData (Android) или StateManagement (iOS). Это простой паттерн, который легко понять, но он масштабируется до сложных приложений.

В: Нужна ли Clean Architecture для маленького приложения?

О: Нет. Начните с MVVM. Clean Architecture имеет смысл, когда приложение становится достаточно сложным, чтобы оправдать дополнительный код.

В: Как избежать утечек памяти?

О: Используйте ViewModel вместо сохранения контекста в других объектах. ViewModel автоматически очищается, когда Activity уничтожена.

В: Что делать, если я унаследовал проект с плохой архитектурой?

О: Рефакторьте постепенно. Каждый раз, когда вы работаете над частью кода, улучшайте её архитектуру. Не пытайтесь переписать всё сразу.

В: Как тестировать архитектуру?

О: Напишите unit-тесты для ViewModel и Use Cases. Они должны работать без UI. Используйте mock’и для зависимостей.

В: Какие инструменты помогут с архитектурой?

О: Для Android — Hilt (DI), Jetpack Compose (UI), Flow (реактивность). Для iOS — SwiftUI, Combine, Dependency Injection вручную или через фреймворки вроде Swinject.

В: Как организовать работу команды с архитектурой?

О: Определите соглашения (conventions) в начале проекта. Каждый разработчик должен следовать одним и тем же правилам. Используйте code review для проверки архитектуры.

В: Нужен ли отдельный слой для каждого экрана?

О: Нет. Несколько экранов могут использовать один ViewModel, если они отображают одни и те же данные. Главное — разделять по логике, а не по UI.

В: Как обновить архитектуру, когда требования меняются?

О: Хорошая архитектура гибкая. Если требования меняются, вы меняете логику в одном слое, не трогая другие. Если это не так — архитектура нужна переработка.

Если обобщить все ответы выше, то главный критерий выбора архитектурного решения — не «правильность по учебнику», а способность команды уверенно развивать продукт. Архитектура должна помогать быстрее вносить изменения, проще тестировать сценарии и безопаснее выполнять рефакторинг. Если она этого не делает, значит, её либо выбрали не по контексту, либо применили формально.

Заключение

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

Начните с простого: отделите логику от UI, используйте ViewModel, управляйте состоянием централизованно. Когда приложение растёт, добавляйте слои и паттерны, которые решают реальные проблемы.

Не переинженеривайте с самого начала. Не игнорируйте архитектуру. Найдите баланс.

И помните: лучшая архитектура — это та, которую ваша команда понимает и может поддерживать. Если ваша архитектура настолько сложна, что только один человек её понимает, это плохая архитектура.

В реальной инженерной работе архитектура оценивается очень просто: насколько безопасно и быстро команда может вносить изменения. Если новая функциональность добавляется без каскадных правок, тесты пишутся без борьбы с фреймворком, code review проходят по смыслу, а не по попыткам угадать побочные эффекты, значит, структура выбрана удачно. Если же каждое изменение требует «осторожно не трогать этот экран, там всё связано со всем», архитектурой нужно заниматься всерьёз.

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