Какие задачи можно решить с помощью многомодульности

Многомодульность в Android: решение архитектурных задач

Многомодульность (multi-module architecture) — это разделение Android-приложения на несколько независимых модулей вместо монолитного структуры. Каждый модуль имеет собственный build.gradle, исходный код и может зависеть от других модулей строго определённым образом. Это одна из главных тенденций в современной Android-разработке.

Основные задачи, решаемые многомодульностью

1. Управление сложностью и масштабируемость

• Большой проект разбивается на логические части
• Каждая команда может работать на своём модуле независимо
• Упрощается навигация по коду
• Меньше merge conflicts при параллельной разработке

2. Переиспользование кода (Reusability)

• Модули можно переиспользовать в других приложениях
• Например, модуль :auth можно подключить в разные проекты
• Feature-модули можно выделять как отдельные библиотеки

3. Тестирование

• Unit-тесты модуля работают быстрее, чем на весь проект
• Модуль можно тестировать изолированно
• Использование mock зависимостей становится проще
• Параллельное тестирование модулей экономит время CI/CD

4. Контроль зависимостей (Dependency Management)

• Чёткая иерархия: какой модуль может зависеть от какого
• Предотвращение циклических зависимостей
• Минимизация coupling между компонентами
• Соблюдение архитектурных принципов (clean architecture, onion)

5. Динамическая доставка (Dynamic Feature Modules)

• Модули можно загружать динамически, не обновляя приложение
• Google Play позволяет доставлять feature-модули отдельно
• Снижает размер APK для базовой установки
• Пользователь скачивает только нужные функции

Типичная структура многомодульного проекта

app/                          // Главное приложение
  - build.gradle            // Зависит от других модулей
  - src/main/AndroidManifest.xml

core/                         // Общие утилиты
  - domain/                 // Бизнес-логика
  - data/                   // Хранилище данных
  - presentation/           // UI компоненты

feature_auth/                 // Модуль авторизации
  - domain/                 // Интерфейсы
  - data/                   // Реализация
  - presentation/           // UI

feature_profile/              // Модуль профиля
  - domain/
  - data/
  - presentation/

shared/                       // Общие компоненты (UI, utils)

Правила многомодульной архитектуры

Слои и направление зависимостей:

Presentation → Domain ← Data
    ↑                      ↓
    └──────────────────────┘

• Presentation зависит от Domain (интерфейсы)
• Data реализует Domain интерфейсы
• Presentation не должна зависеть от Data напрямую
• Зависимости идут только "внутрь" (от outer слоёв к inner)

Между модулями:

• :core — no зависимостей (или только на stdlib)
• :feature_X — зависит от :core, не зависит от других feature
• :app — зависит от всех других модулей

Практический пример (build.gradle.kts)

// app/build.gradle.kts
dependencies {
    implementation(project(":feature_auth"))
    implementation(project(":feature_profile"))
    implementation(project(":core"))
}

// feature_auth/build.gradle.kts
dependencies {
    implementation(project(":core"))
    // НЕ может зависеть от :feature_profile
}

// core/build.gradle.kts
dependencies {
    // Только внешние библиотеки (Retrofit, Room, etc.)
}

Инструменты для контроля зависимостей

• ModuleGraph Gradle Plugin — визуализирует граф зависимостей
• Lint checks — предупреждает о forbidden зависимостях
• build-logic (buildSrc) — централизованное управление версиями и конфигом

Вызовы многомодульности

• Сложность setup: требует тщательного планирования
• Скорость gradle build: больше модулей = медленнее сборка (решается кешированием)
• Синхронизация версий: нужен central management (Version Catalog)

Многомодульность — это не просто "хорошая практика", это необходимость для растущих проектов. Компании вроде Google, Yandex, Ozon используют многомодульные архитектуры для масштабирования разработки команды.