Мы проектируем архитектуру мобильных приложений, чтобы избежать ситуации, когда через 6 месяцев добавление пуш-уведомлений требует переписывания трёх экранов из-за бизнес-логики, зашитой в ViewController, или навигации, привязанной к AppDelegate. Наша команда с опытом более 7 лет и с 50+ реализованными проектами знает, как заложить масштабируемость, тестируемость и производительность с первого дня. Проектирование архитектуры — это инвестиция, которая окупается при первом значимом изменении требований. Например, один из наших клиентов (логистическая компания) после рефакторинга на Clean Architecture сократил время добавления новой фичи с 2 недель до 2 дней, что сэкономило более $50 000 на доработках в первый год, а затем экономия составила ещё $20 000 за полгода за счёт снижения стоимости изменений на 40%.
Какой паттерн архитектуры выбрать для вашего проекта?
MVVM стал стандартом де-факто для iOS (SwiftUI + Combine), Android (Jetpack Compose + ViewModel) и Flutter (BLoC/Riverpod). Но «поставить MVVM» без понимания масштаба проекта — значит переусложнить маленькое приложение или не структурировать большое. Факторы, влияющие на выбор:
- Команда и её опыт. Если команда не работала с VIPER — не ставить VIPER. Освоение паттерна в продакшене дороже его преимуществ.
- Масштаб и модульность. 5 экранов — достаточно простого MVVM без Clean Architecture. 50 экранов с командой из 8 человек — Clean Architecture обязательна, иначе неизбежны конфликты в общих файлах и отсутствие изоляции.
- Требования к тестируемости. VIPER и Clean Architecture дают лучшую тестируемость через инверсию зависимостей, но требуют дисциплины от всей команды.
- Платформа. iOS, Android и Flutter имеют разные нативные паттерны: VIPER органичен для iOS/UIKit, MVP исторически популярен на Android, BLoC стал стандартом для Flutter.
Почему важна модульная структура?
Для крупных проектов (50+ экранов, команда 5+ человек) модульность критична. Разбивка на feature-модули (auth, profile, payments, feed) позволяет параллельно вести разработку и управлять временем сборки. На iOS используем Swift Package Manager, на Android — Gradle multi-module, на Flutter — Dart packages внутри монорепо. В одном из проектов мы внедрили модульную архитектуру и сократили конфликты слияния на 70%.
Что входит в проектирование архитектуры?
Это не просто схема в Miro с прямоугольниками «Model — View — ViewModel». Полноценное проектирование включает:
Слоевая модель (layering). Определяем границы между слоями: Presentation / Domain / Data. Документируем правила: domain-слой не знает о Flutter/UIKit, data-слой не знает о конкретном UI-фреймворке. Dependency Rule — зависимости только внутрь, никогда наружу.
Dependency Injection стратегия. Выбор DI-контейнера: iOS — Resolver / Swinject / ручной чистый DI, Android — Hilt (Dagger2 с кодогенерацией), Flutter — GetIt + injectable. Проектируем граф зависимостей, определяем времена жизни объектов (singleton / scoped / transient).
lib/ app/ app.dart core/ network/ database/ di/ features/ auth/ presentation/ domain/ data/ profile/ presentation/ domain/ data/ Каждый feature-модуль содержит свои presentation, domain и data, что позволяет изолировать фичи и переиспользовать код.
Сравнение подходов к управлению состоянием
| Критерий | BLoC (Flutter) | ViewModel (Android) | Combine (iOS) |
|---|---|---|---|
| Порог входа | Средний | Низкий | Средний |
| Тестируемость | Высокая | Средняя | Высокая |
| Реактивность | Stream | LiveData/Flow | Publisher |
| Популярность | Стандарт Flutter | Стандарт Android | Штатный iOS |
Сетевой слой: Retrofit (Android), Moya (iOS), Dio (Flutter). Interceptors для авторизации (token refresh), логирования, retry-логики. Обработка ошибок: маппинг HTTP-кодов в доменные ошибки, не пробрасывать DioException в presentation-слой.
Документация архитектуры
Результат работы — не только работающий scaffold. Документируем в виде:
- ADR (Architecture Decision Records) — почему выбрали именно этот паттерн, какие альтернативы рассматривали
- Диаграммы компонентов и зависимостей (C4 model: Context → Container → Component)
- Coding conventions и примеры для каждого слоя
- Шаблонная структура feature-модуля, которой следует вся команда
Практический кейс из нашей практики
На проекте Flutter-приложения для логистики (30+ экранов, реалтайм трекинг, офлайн-работа водителя) первоначальная архитектура была «BLoC везде без чёткого разделения слоёв». Через 4 месяца: BLoC напрямую вызывал Dio, тесты не писались (невозможно изолировать), добавление новой фичи требовало правок в 5–7 несвязанных файлах.
Мы провели рефакторинг на Clean Architecture с GetIt + injectable, go_router, drift для офлайн. Это заняло 3 недели, но следующие 6 месяцев команда добавляла фичи в 2 раза быстрее. Клиент отметил, что стоимость изменений снизилась на 40%, что в денежном выражении составило более $20 000 за полгода.
Сравнение архитектурных паттернов
| Критерий | MVC/MVP | MVVM | Clean Architecture |
|---|---|---|---|
| Порог входа | Низкий | Средний | Высокий |
| Тестируемость | Низкая | Средняя | Высокая |
| Масштаб команды | 1–2 чел. | 2–5 чел. | 5+ чел. |
| Время на проектирование | 0.5 дня | 1 день | 3–5 дней |
| Окупаемость | С первого месяца | С 3-го месяца | С 6-го месяца |
Мы рекомендуем Clean Architecture для проектов, которые планируют жить более года и развиваться командой. Для быстрых прототипов или маленьких приложений достаточно MVVM.
Процесс и сроки
- Аудит требований — функциональные и нефункциональные требования, NFR по производительности и офлайн.
- Анализ платформы и стека — iOS / Android / Flutter / cross-platform, существующий код если есть.
- Проектирование — выбор паттернов, документирование решений, ADR.
- Реализация scaffold — базовая структура проекта с примерами для каждого слоя.
- Код-ревью и онбординг — объяснение команде принципов, code review первых фич.
Проектирование архитектуры занимает от 3 до 5 дней. Для legacy-рефакторинга с существующим кодом — больше. Стоимость рассчитывается индивидуально после анализа требований и состава команды. Закажите проектирование архитектуры — мы поможем выбрать оптимальную архитектуру для вашего приложения. Получите консультацию, заполнив форму на сайте.
Apple Human Interface Guidelines рекомендуют ориентироваться на платформенные паттерны, но при кроссплатформенной разработке важно соблюдать модульность и Dependency Rule.