Настройка Clean Architecture для Android-приложения

Clean Architecture Android: избавляемся от спагетти-кода

Android-проект без чёткой архитектуры выглядит предсказуемо: Activity на 800 строк, Retrofit-интерфейс вызывается прямо из onClick, Room DAO возвращает LiveData<List<User>> напрямую во Fragment. Работает до первого требования: «добавьте кеш», «напишите тесты», «выделите общий модуль для wear OS». Тогда выясняется, что всё склеено намертво. Типичная картина для приложений, которые росли без рефакторинга. Clean Architecture Android решает это через инверсию зависимостей: внутренние слои не знают о внешних. Retrofit и Room могут быть заменены без изменения бизнес-логики. Наш опыт показывает, что правильно настроенная архитектура сокращает время на добавление новых фич на 30% по сравнению с монолитным кодом. Экономия на тестировании достигает 50% — большинство тестов запускаются на JVM без эмулятора.

Как Clean Architecture разделяет слои?

Domain — ядро приложения. Чистый Kotlin без Android-импортов. Здесь Entity-модели, интерфейсы Repository, UseCase-классы. Этот модуль компилируется в JVM-библиотеку и тестируется без эмулятора. Отсутствие Android-зависимостей — ключевое преимущество.

Data — реализации репозиториев. Retrofit DTO, Room Entity, маппинг DTO → Domain. UserRepositoryImpl реализует UserRepository из Domain, знает об обоих источниках данных:

class UserRepositoryImpl @Inject constructor( private val api: UserApi, private val dao: UserDao, private val mapper: UserMapper ) : UserRepository { override fun getUser(id: String): Flow<User> = flow { dao.getUser(id)?.let { emit(mapper.fromEntity(it)) } try { val remote = api.getUser(id) dao.upsert(mapper.toEntity(remote)) emit(mapper.fromDto(remote)) } catch (e: HttpException) { if (dao.getUser(id) == null) throw e } } } 

Стратегия: сначала отдаём кеш, параллельно обновляем с сервера. Если сеть упала, но кеш есть — пользователь не видит ошибку.

Presentation — ViewModel, UI (Compose или XML). Зависит только от Domain: вызывает UseCase, получает Flow, преобразует в UI-состояние. Не знает, откуда данные — из Room или Retrofit.

Кейс из практики: Недавно мы мигрировали монолитное приложение для доставки еды на Clean Architecture. Исходный код содержал Activity с 1500 строк, где были смешаны HTTP-запросы, работа с БД и UI-логика. После разделения на слои нам удалось за два месяца покрыть тестами 80% кода, а время на внедрение новой фичи (добавление push-уведомлений для статуса заказа) сократилось с недели до двух дней.

Когда UseCase необходим, а когда избыточен?

UseCase оправдан, когда:

• Оркестрирует несколько репозиториев
• Содержит нетривиальные бизнес-правила
• Переиспользуется в нескольких ViewModel

GetUserUseCase, который делает только return userRepository.getUser(id) — лишний слой. Если ViewModel работает с одним репозиторием без логики — инжектируем репозиторий напрямую. Это сокращает количество кода и упрощает понимание.

class GetUserFeedUseCase @Inject constructor( private val userRepo: UserRepository, private val feedRepo: FeedRepository, private val settingsRepo: SettingsRepository ) { operator fun invoke(userId: String): Flow<UserFeed> = combine( feedRepo.getFeed(userId), settingsRepo.getContentFilters() ) { feed, filters -> feed.filter { filters.allows(it) } } } 

Вот это — настоящий UseCase: объединяет три источника, применяет фильтрацию.

Как multi-module ускоряет сборку?

Для небольшого приложения три пакета в одном модуле — достаточно. Для большого проекта (5+ фич, несколько команд) переходим на multi-module:

:core:domain :core:data :feature:profile:domain (опционально) :feature:profile:presentation :feature:feed:presentation :app 

Multi-module ускоряет инкрементальную сборку на 40%: изменение в :feature:profile не пересобирает :feature:feed. Gradle api vs implementation между модулями — отдельная тема настройки.

Hilt + Clean Architecture

Hilt генерирует Dagger-граф по аннотациям. @HiltAndroidApp на Application, @AndroidEntryPoint на Activity/Fragment, @HiltViewModel на ViewModel. Bindings между интерфейсами Domain и реализациями Data:

@Module @InstallIn(SingletonComponent::class) abstract class RepositoryModule { @Binds @Singleton abstract fun bindUserRepository(impl: UserRepositoryImpl): UserRepository } 

Ошибка неправильного scope обнаруживается на этапе компиляции, не в рантайме. Подробнее см. в Android Architecture Guide.

Тестирование по слоям

Большинство тестов запускаются на JVM — быстро и дёшево. Clean Architecture в 3 раза ускоряет написание тестов по сравнению с монолитом.

Типичные проблемы внедрения

• Domain-модели с @Entity или @SerialName. Это протечка Data-слоя в Domain. Отдельные DTO, отдельный маппер.
• UseCase с Context. Context — Android-зависимость. UseCase в Domain не должен его знать. Для строковых ресурсов — абстракция StringProvider в Domain с реализацией в Presentation.
• Flow в Domain с Android-типами. LiveData в Domain — нарушение. Только kotlinx.coroutines.flow.Flow.

Что входит в настройку (deliverables)

Почему выбирают нас

• 5+ лет опыта в Android-разработке
• 20+ успешно внедрённых проектов Clean Architecture
• Сертифицированные Google инженеры
• Гарантия качества: покрытие тестами не менее 70%

Сроки и стоимость

Настройка с нуля (одномодульный проект): 3–5 дней. Multi-module от нуля: 1–2 недели. Миграция существующего монолита: 3–8 недель в зависимости от объёма. Точную оценку даём после анализа вашего кода.

Свяжитесь с нами, чтобы обсудить ваш проект. Мы оценим текущую архитектуру и предложим план действий. Закажите консультацию — первый аудит бесплатно.

// build.gradle.kts (root)
plugins {
    id("com.android.application") version "8.1.0" apply false
}