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

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

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

Clean Architecture решает это через инверсию зависимостей: внутренние слои не знают о внешних. Retrofit и Room могут быть заменены без изменения бизнес-логики.

Три слоя и их границы

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

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.

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 ускоряет инкрементальную сборку: изменение в :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 обнаруживается на этапе компиляции, не в рантайме.

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

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

Частые ошибки при внедрении

Domain-модели с @Entity или @SerialName. Это протечка Data-слоя в Domain. Отдельные DTO, отдельный маппер.

UseCase с Context. Context — Android-зависимость. UseCase в Domain не должен его знать. Для строковых ресурсов — абстракция StringProvider в Domain с реализацией в Presentation.

Flow в Domain с Android-типами. LiveData в Domain — нарушение. Только kotlinx.coroutines.flow.Flow.

Что делаем при настройке

Проектируем модульную структуру под размер проекта. Настраиваем Hilt с правильными scope. Реализуем первый фича-модуль как образец: UseCase + Repository + ViewModel + тесты всех слоёв. Пишем Gradle convention plugins для единообразия конфигурации между модулями.

Сроки

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