Был ли последний проект многомодульным

Был ли последний проект многомодульным?

Да, мой последний проект был полноценным многомодульным приложением, разработанным с использованием modularization в Android на Kotlin. Мы сознательно выбрали этот подход, так как приложение выросло до более чем 500 экранов и 200+ тысяч строк кода, с командой из 15+ разработчиков, работающих параллельно. Без модульности поддержка и развитие такого масштабного проекта стали бы крайне затруднительными.

Основные модули в проекте

Мы структурировали проект по принципу feature-based modularization, с чётким разделением ответственности:

1. App-модуль (:app)

Собирательный модуль, который объединяет все feature-модули и содержит минимальную логику:

• Точка входа Application-класс с инициализацией DI-графа.
• Манифест с объявлением основных компонентов.
• Конфигурация сборки и настройки для разных сборок (debug, release, staging).

// Пример настройки зависимостей в build.gradle.kts :app
dependencies {
    implementation(project(":core"))
    implementation(project(":feature:auth"))
    implementation(project(":feature:home"))
    implementation(project(":feature:profile"))
    // ... другие feature-модули
}

2. Core-модули (:core:network, :core:database, :core:ui)

Набор технических модулей, предоставляющих общую инфраструктуру:

• :core:network – инкапсуляция работы с REST API через Retrofit, interceptors, модели данных.
• :core:database – настройка Room, DAO-интерфейсы, миграции.
• :core:ui – общие UI-компоненты (кастомные View, стили, базовые Activity/Fragment).
• :core:utils – расширения Kotlin, утилитные классы.

3. Feature-модули (:feature:auth, :feature:home, :feature:profile)

Независимые модули, представляющие собой логически завершённые функциональные блоки:

• Каждый feature-модуль имеет свою внутреннюю структуру (presentation, domain, data слои по принципу Clean Architecture).
• Изоляция зависимостей – feature-модули не знают друг о друге, общение происходит через публичные интерфейсы или навигацию.
• Индивидуальная конфигурация – возможность включать/отключать модули для разных сборок (например, демо-версия без премиум-функций).

// Пример feature-модуля :feature:auth, его публичный интерфейс для навигации
interface AuthNavigation {
    fun navigateToHome(context: Context)
    fun navigateToRegistration(context: Context)
}

4. Library-модули (:lib:analytics, :lib:push)

Модули-обёртки над сторонними SDK или специфическими библиотеками, чтобы изолировать их влияние и упростить замену.

Преимущества, которые мы получили

• Ускорение сборки за счёт incremental builds и кэширования модулей в CI/CD.
• Чёткие границы ответственности – уменьшились конфликты в коде и упростилось ревью.
• Улучшенная тестируемость – модули можно тестировать изолированно, с моками зависимостей.
• Динамическая доставка – возможность выносить отдельные модули в Dynamic Feature Modules для уменьшения размера APK.
• Масштабируемость команды – разные команды могут работать над разными модулями параллельно.

Вызовы и решения

• Циклические зависимости – решены через выделение общих интерфейсов в core-модули.
• Консистентность зависимостей – использовали Version Catalogs в Gradle для централизованного управления версиями.
• Сложность навигации – внедрили Navigator-паттерн с централизованной регистрацией маршрутов.

В итоге, переход на многомодульную архитектуру стал ключевым фактором в поддержании высокой скорости разработки, качества кода и эффективности команды. Это опыт, который я считаю обязательным для современных сложных Android-приложений.