Clean Architecture Android: позбуваємося спагеті-коду

Clean Architecture Android: позбуваємося спагеті-коду

Android-проєкт без чіткої архітектури виглядає передбачувано: Activity на 800 рядків, Retrofit-інтерфейс викликається прямо з onClick, Room DAO повертає LiveData<List<User>> напряму у Fragment. Працює до першої вимоги: «додайте кеш», «напишіть тести», «виділіть спільний модуль для wear OS». Тоді з'ясовується, що все склеєно намертво. Типова картина для додатків, які росли без рефакторингу. Clean-архітектура 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-сповіщень для статусу замовлення) скоротився з тижня до двох днів. За підрахунками, Clean Architecture економить до $15,000 на рік для команди з 5 розробників за рахунок скорочення технічного боргу.

Визначення необхідності 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.

Тестування за шарами

Більшість тестів (80%) запускаються на 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.

Як впровадити Clean Architecture покроково

1. Виділити Domain-модуль з чистим Kotlin.
2. Визначити інтерфейси репозиторіїв та UseCase.
3. Реалізувати Data-модуль з Retrofit/Room та мапперами.
4. Налаштувати Hilt для впровадження залежностей.
5. Підключити Presentation шар через ViewModel.
6. Написати тести на JVM.

Що входить у налаштування (deliverables)

Наші переваги

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

Терміни та вартість

Налаштування з нуля (одномодульний проєкт): 3–5 днів, вартість від $500. Multi-module з нуля: 1–2 тижні, вартість від $1500. Міграція існуючого моноліту: 3–8 тижнів залежно від обсягу, вартість від $3000. Точну оцінку даємо після аналізу вашого коду.

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

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

Як Clean Architecture допомагає прискорити розробку?

За рахунок чіткого розділення обов'язків і інверсії залежностей, команди працюють паралельно над різними шарами, що скорочує час випуску релізів.