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

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

MVI (Model-View-Intent) — эволюция MVVM для приложений со сложным состоянием. Если в вашем приложении много экранов, которые влияют друг на друга, много асинхронных операций и сложная логика переходов — MVI может быть лучшим выбором.

Принципы MVI

Главное отличие MVI от MVVM — строгость и предсказуемость. Вместо нескольких изменяемых переменных состояния, MVI использует единый неизменяемый объект, который полностью описывает экран.

Однонаправленный поток данных. Данные движутся только в одном направлении: от Intent к State. Нет обратных связей, которые могут создать неожиданные циклы.

            Intent → Reducer → State → View
   ↑                        ↓
   ←      User Action       ←
          

Неизменяемое состояние (Immutable State). Состояние нельзя изменить напрямую — можно только создать новое состояние на основе предыдущего и действия. Это исключает целый класс багов, связанных с гонками состояний.

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

Компоненты MVI

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

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

Reducer (редьюсер) — чистая функция, которая принимает текущее состояние и Intent, возвращает новое состояние. Никаких побочных эффектов, никаких сетевых запросов — только трансформация данных.

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

View — отображает State. Когда State меняется — View перерисовывается. Никакой логики в View, только маппинг State на UI-элементы.

Преимущества MVI

Предсказуемость. Зная текущее состояние и входящий Intent, всегда можно предсказать следующее состояние. Это упрощает отладку и понимание кода.

Воспроизводимость багов. Можно записать последовательность Intent и воспроизвести баг на любом устройстве. Больше никаких «у меня работает, а у пользователя нет».

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

Сложные сценарии. MVI отлично справляется с экранами, где много асинхронных операций и сложная логика переходов — например, многошаговые формы или real-time обновления.

Когда выбирать MVI

Выбор между MVVM и MVI — не вопрос «что лучше», а вопрос соответствия задаче. Для простых экранов MVI избыточен, для сложных — необходим.

MVI: overhead или инвестиция?

MVI требует больше кода, чем MVVM. Каждый экран — это State-класс, набор Intent'ов, Reducer. Для простого приложения это избыточно и замедляет разработку без видимой пользы.

Но для сложного приложения с десятками экранов, командой из 5+ разработчиков и планами на многолетнее развитие — MVI окупается. Предсказуемость и тестируемость экономят время на отладке и поддержке, а строгая структура упрощает онбординг новых членов команды.

6. Clean Architecture: разделяй и властвуй

MVVM и MVI — это паттерны организации presentation-слоя. Они отвечают на вопрос «как связать UI с логикой экрана». Но когда приложение растёт, появляется другой вопрос: «как организовать всё приложение целиком?»

Clean Architecture — это не конкретный паттерн, а набор принципов организации кода, предложенный Робертом Мартином (Uncle Bob). Главная идея: разделить приложение на слои с чёткими зависимостями, где внутренние слои не знают о внешних.

Принцип зависимостей

В Clean Architecture зависимости направлены внутрь. Внешние слои знают о внутренних, но внутренние не знают о внешних. Это ключевой принцип, который обеспечивает гибкость и тестируемость.

            [Frameworks & Drivers] → [Interface Adapters] → [Use Cases] → [Entities]
     (внешний слой)                                            (ядро)
          

Entities (сущности) — бизнес-объекты и правила, которые не зависят от приложения. Например, правила расчёта скидки или валидация данных. Это самый стабильный слой, который меняется редко.

Use Cases (сценарии использования) — бизнес-логика приложения. «Оформить заказ», «Получить список товаров», «Авторизовать пользователя». Каждый Use Case делает одно дело и делает его хорошо.

Interface Adapters (адаптеры) — преобразование данных между слоями. ViewModel, Presenter, Repository. Эти компоненты переводят данные из формата, удобного для Use Cases, в формат, нужный UI или базе данных.

Frameworks & Drivers — внешние зависимости. UI-фреймворк, база данных, сеть. Это самый изменчивый слой, который легко заменить без переписывания бизнес-логики.

Преимущества Clean Architecture

Независимость от фреймворков. Бизнес-логика не знает о Retrofit, Room или Compose. Можно заменить любой фреймворк, не трогая ядро — полезно при миграции на новые версии или смене технологий.

Тестируемость. Каждый слой тестируется изолированно. Use Cases — unit-тестами без моков инфраструктуры, Interface Adapters — с моками.

Понятная структура. Новый разработчик понимает, где искать бизнес-логику, где — работу с данными, где — UI. Код организован не по техническим критериям, а по функциональным.

Масштабируемость. Добавление нового Use Case не затрагивает существующие. Модули независимы, команда может работать параллельно над разными частями системы.

Clean Architecture на практике

Теория хороша, но как это выглядит в реальном проекте? Вот типичная структура папок:

            app/
├── data/                  # Data Layer
│   ├── api/               # Сетевые запросы
│   ├── database/          # Локальная БД
│   └── repository/        # Реализации репозиториев
├── domain/                # Domain Layer (чистый Kotlin/Swift)
│   ├── model/             # Бизнес-сущности
│   ├── repository/        # Интерфейсы репозиториев
│   └── usecase/           # Use Cases
└── presentation/          # Presentation Layer
    ├── feature1/          # Экраны фичи 1
    └── feature2/          # Экраны фичи 2
          

Обратите внимание: domain-слой не содержит зависимостей от Android или iOS SDK. Это чистый Kotlin или Swift, который можно тестировать без эмулятора.

Когда Clean Architecture избыточна

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

Главное правило: сложность архитектуры должна соответствовать сложности продукта. Не стоит строить небоскрёб, когда нужен дачный домик.

7. Структура мобильного приложения по слоям

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

Presentation Layer

Слой представления отвечает за UI и взаимодействие с пользователем. Это «лицо» вашего приложения — всё, что видит и с чем взаимодействует пользователь.

Компоненты:

• Screens / Views — экраны приложения, декларативное описание UI
• ViewModels — хранят состояние и логику UI, связывают экран с бизнес-логикой
• UI State — неизменяемые классы состояния, полностью описывающие экран
• Navigation — логика переходов между экранами

Принципы:

• ViewModel не знает о конкретной реализации View — это обеспечивает тестируемость
• UI State содержит всё необходимое для отрисовки экрана — никаких скрытых зависимостей
• Нет бизнес-логики — только логика отображения и взаимодействия

Domain Layer

Слой бизнес-логики — сердце приложения. Здесь живёт вся уникальная ценность вашего продукта, то, что отличает его от конкурентов.

Компоненты:

• Use Cases — бизнес-операции. Каждый Use Case делает одно дело
• Entities — бизнес-объекты и правила их валидации
• Repository Interfaces — контракты для работы с данными

Принципы:

• Чистый Kotlin/Swift — никаких зависимостей от фреймворков. Это самый портабельный слой
• Один Use Case — одно действие. «Оформить заказ», не «Управлять заказами»
• Валидация и бизнес-правила живут здесь, не в UI и не в data-слое

Пример Use Case:

            class PlaceOrderUseCase(
    private val orderRepository: OrderRepository,
    private val paymentService: PaymentService
) {
    suspend fun execute(order: Order): Result<OrderConfirmation> {
        // Валидация
        if (order.items.isEmpty()) return Result.Error("Empty cart")

        // Бизнес-логика
        val payment = paymentService.process(order.total)
        if (payment.isFailure) return Result.Error("Payment failed")

        // Сохранение
        return orderRepository.create(order)
    }
}
          

Data Layer

Слой данных отвечает за получение и сохранение информации. Он скрывает от бизнес-логики детали работы с API, базой данных и кэшем.

Компоненты:

• Repository Implementations — реализации интерфейсов из Domain
• Data Sources — источники данных (API, база, кэш)
• DTOs — объекты для передачи данных, специфичные для API или базы
• Mappers — преобразование DTO ↔ Entity

Принципы:

• Repository решает, откуда взять данные (сеть, кэш, база) — это его ответственность
• Data Source знает специфику конкретного источника — формат запросов, обработку ошибок
• Domain Layer не знает о деталях реализации — только о контрактах

Взаимодействие слоёв

На практике данные текут через слои сверху вниз (от пользователя к хранилищу) и обратно:

            ┌─────────────────────────────────────────────────────────────┐
│                    Presentation Layer                        │
│  ┌─────────┐   ┌───────────────┐   ┌─────────────────┐     │
│  │  View   │ ←→│   ViewModel   │ ←→│   Navigation    │     │
│  └─────────┘   └───────────────┘   └─────────────────┘     │
│                        │                                     │
│                        ↓                                     │
├─────────────────────────────────────────────────────────────┤
│                      Domain Layer                            │
│  ┌─────────────┐  ┌─────────────┐  ┌────────────────┐      │
│  │  Use Cases  │←→│  Entities   │  │  Repositories  │      │
│  │             │  │             │  │  (interfaces)  │      │
│  └─────────────┘  └─────────────┘  └────────────────┘      │
│                        ↑                                     │
│                        │                                     │
├─────────────────────────────────────────────────────────────┤
│                       Data Layer                             │
│  ┌────────────────┐  ┌──────────────┐  ┌────────────┐      │
│  │  Repositories  │←→│ Data Sources │←→│  Mappers   │      │
│  │(implementations)│  │  (API, DB)  │  │            │      │
│  └────────────────┘  └──────────────┘  └────────────┘      │
└─────────────────────────────────────────────────────────────┘
          

8. Проектирование приложения: пошаговый процесс

Теория изучена, паттерны понятны — но как применить эти знания на практике? Вот пошаговый процесс проектирования архитектуры, который мы используем в Surf для каждого нового проекта.

Шаг 1: Анализ требований

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

Вопросы о бизнесе:

• Какой срок жизни продукта? (MVP на полгода или платформа на 5 лет)
• Какой размер команды сейчас и в перспективе?
• Насколько критичны стабильность и скорость развития?
• Какие ресурсы доступны на поддержку?

Вопросы о продукте:

• Сколько экранов и функций в первой версии и в roadmap?
• Какая сложность бизнес-логики?
• Нужен ли оффлайн-режим?
• Какие интеграции с внешними системами?

Шаг 2: Выбор технологического стека

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

Шаг 3: Выбор архитектурного паттерна

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

Шаг 4: Определение модулей

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

По фичам (Feature-based):

            features/
├── auth/
├── catalog/
├── cart/
├── checkout/
├── profile/
└── orders/
          

По слоям (Layer-based):

            app/
├── data/
├── domain/
└── presentation/
          

Гибридный подход (рекомендуем):

            core/                     # Общий код
├── data/
├── domain/
└── ui/
features/                 # Фичи
├── auth/
│   ├── data/
│   ├── domain/
│   └── presentation/
└── catalog/
    ├── data/
    ├── domain/
    └── presentation/
          

Гибридный подход сочетает преимущества обоих методов: фичи изолированы для параллельной разработки, а общий код вынесен в core-модули.

Шаг 5: Определение контрактов

Зафиксируйте интерфейсы между слоями до начала разработки. Это позволяет командам работать параллельно: один разрабатывает UI, другой — бизнес-логику, третий — интеграции.

• Какие данные передаёт Repository?
• Какие методы выставляет UseCase?
• Какие события отправляет ViewModel?

Чек-лист проектирования

Перед началом разработки убедитесь, что все ключевые решения приняты и зафиксированы:

• [ ] Проанализированы бизнес-требования
• [ ] Выбран технологический стек
• [ ] Определён архитектурный паттерн
• [ ] Разбиты модули приложения
• [ ] Зафиксированы контракты между слоями
• [ ] Определены инструменты для DI, навигации, работы с сетью
• [ ] Подготовлен шаблон проекта с базовой структурой

9. Типичные архитектурные ошибки

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

Ошибка 1: «God Object» — объект-бог

Проблема: Один класс делает слишком много. ViewModel на 2000 строк, который обрабатывает 15 разных экранов. Activity, которая одновременно работает с сетью, базой данных и UI.

Почему это плохо: Невозможно тестировать — слишком много зависимостей. Сложно понять — нужно держать в голове весь контекст. Изменение в одном месте ломает другое — неочевидные связи.

Решение: Single Responsibility Principle. Один класс — одна ответственность. Разбивайте крупные классы на мелкие, специализированные. ViewModel для одного экрана, не для группы экранов.

Ошибка 2: Бизнес-логика в UI

Проблема: Расчёт скидки происходит прямо в Composable-функции. Валидация формы — в обработчике клика. Решение о навигации — в самом экране.

Почему это плохо: Логику невозможно переиспользовать. При изменении UI нужно переносить логику. Тестирование только через UI-тесты — медленно и нестабильно.

Решение: Выносите бизнес-логику в UseCase или ViewModel. UI должен только отображать готовые данные и передавать события.

Ошибка 3: Игнорирование асинхронности

Проблема: Синхронные вызовы в UI-потоке блокируют интерфейс. Отсутствие обработки состояний загрузки и ошибок — пользователь видит пустой экран.

Почему это плохо: Приложение «зависает» во время сетевых запросов. Пользователь не понимает, что происходит. Crash при ошибках сети превращает баг в катастрофу.

Решение: Всегда моделируйте состояния: Loading, Success, Error. Используйте корутины (Kotlin) или async/await (Swift). Показывайте пользователю, что происходит.

Ошибка 4: Жёсткая связанность

Проблема: Классы напрямую создают свои зависимости. UserViewModel создаёт UserRepository, который создаёт ApiClient. Цепочка зависимостей тянется через всё приложение.

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

Решение: Dependency Injection. Hilt для Android, built-in DI для SwiftUI, GetIt для Flutter. Зависимости передаются извне, а не создаются внутри.

Ошибка 5: Преждевременная оптимизация

Проблема: Микросервисная архитектура для MVP. Сложные паттерны в приложении из 5 экранов. Clean Architecture с Use Cases для CRUD-операций.

Почему это плохо: Overhead на поддержку сложности съедает время. Медленная разработка — конкуренты обгоняют. Команда тратит время на архитектуру вместо продукта.

Решение: Выбирайте сложность, соответствующую проекту. Для MVP — простой MVVM. Усложняйте по мере роста, когда появляется реальная потребность.

Ошибка 6: Отсутствие архитектуры

Проблема: «Сейчас быстро сделаем, потом перепишем». Код пишется без структуры, каждый разработчик делает по-своему. Нет единых соглашений.

Почему это плохо: Через полгода — хаос. Добавление фичи занимает в 5 раз больше времени. Новые разработчики месяцами входят в проект, потому что нет логики в организации кода.

Решение: Выделите время на проектирование в начале. 1-2 недели на архитектуру сэкономят месяцы переделок.

10. Как выбрать архитектуру для вашего проекта

Универсальной «лучшей» архитектуры не существует. Выбор зависит от контекста: размера проекта, команды, бюджета, сроков. Попытка применить enterprise-архитектуру к MVP — такая же ошибка, как отсутствие архитектуры в крупном проекте.

Матрица выбора

Вот практические рекомендации для типичных сценариев:

Пошаговый алгоритм выбора

Если таблица не даёт однозначного ответа, пройдите по этим шагам:

Шаг 1: Оцените сложность продукта

• Простой (< 15 экранов, CRUD-операции) → MVVM
• Средний (15-40 экранов, интеграции) → MVVM + Clean Architecture
• Сложный (40+ экранов, сложная бизнес-логика) → MVI + Clean Architecture

Шаг 2: Оцените размер команды

• 1-2 разработчика → Проще лучше, меньше абстракций
• 3-5 разработчиков → Нужна структура для параллельной работы
• 5+ разработчиков → Строгие контракты, модульность обязательна

Шаг 3: Оцените срок жизни продукта

• MVP для проверки гипотезы → Минимальная архитектура
• Продукт на 2-3 года → Средняя сложность
• Платформа на 5+ лет → Максимальная гибкость и масштабируемость

Шаг 4: Оцените критичность

• Некритичный сервис → Можно позволить компромиссы
• Критичный (платежи, здоровье, безопасность) → Максимальная надёжность

Наш подход в Surf

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

Для MVP и небольших проектов: MVVM с чётким разделением на слои, но без избыточных абстракций. Это позволяет быстро выйти на рынок и проверить гипотезу.

Для средних проектов: MVVM + Clean Architecture. Разделение на data/domain/presentation даёт гибкость для роста, при этом не перегружая кодовую базу.

Для крупных проектов: MVI + Clean Architecture + модульность. Каждая фича — отдельный модуль со своей архитектурой. Это обеспечивает независимость команд и предсказуемость поведения.

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

Заключение

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

Резюме ключевых решений

5 принципов хорошей архитектуры

1. Разделение ответственности. Каждый компонент делает одно дело и делает его хорошо. Нет «god objects», нет смешения логики с отображением.
2. Зависимости направлены внутрь. UI зависит от логики, логика не знает об UI. Это обеспечивает гибкость и тестируемость.
3. Тестируемость по умолчанию. Код, который нельзя протестировать — это долг, который придётся оплатить багами в продакшене.
4. Простота над сложностью. Не усложняйте, пока не появится необходимость. MVP не требует enterprise-архитектуры.
5. Эволюция, не революция. Архитектура должна позволять постепенные изменения без переписывания с нуля.