Правила именования модулей в Android‑проектах

Короткий ответ: используйте kebab-case с ясными префиксами (feature-, data-, core-, library-), уникальные описательные имена, максимум 2–3 уровня вложенности и избегайте точек/подчёркиваний — это упрощает include в settings.gradle и работу Gradle.

Базовые конвенции

  • Формат: только строчные буквы, цифры и дефисы (kebab-case). Примеры: app, feature-user-profile, core-network.
  • Префиксы: feature- для фич, data- для источников данных, core- для общих компонентов, library- или lib- для библиотек.
  • Вложенность: не более 2–3 уровней (например :feature:shopping:cart). Длинные и глубоко вложенные пути затрудняют навигацию и CI.
  • Уникальность: имя должно однозначно отражать содержание модуля (data-user-local vs data-user-remote).
  • Запреты: не используйте CamelCase, snake_case, пробелы, точки или спецсимволы (❌ featureUserProfile, data_base, core.common).

Если модуль маленький и относится к одной фиче, лучше вложить его в namespace фичи (feature-shopping:cart), а не создавать отдельную глобальную feature-cart.

Шаблоны для типов модулей (практика)

  • app — корневой модуль приложения.
  • core-* — утилиты и общие UI/Network/DI (core-ui, core-network, core-logging).
  • feature-* — экраны и фичи (feature-auth-login, feature-user-profile).
  • domain* или domain-* — бизнес-логика (domain, domain-user).
  • data-* — источники данных и репозитории (data-remote, data-local, data-repository).
  • library-* — переиспользуемые библиотеки (library-analytics, library-navigation).

Пример структуры в settings.gradle: include(":app") include(":core:common") include(":core:network") include(":feature:home") include(":feature:settings") include(":data:remote") include(":domain")

Как выбрать имя при создании нового модуля

  1. Определите роль (фича, данные, UI, библиотека).
  2. Выберите префикс: feature-, data-, core-, library-.
  3. Добавьте контекст: уточняйте подсистему или экран (feature-user-profile вместо feature-profile).
  4. Проверьте зависимости и уникальность: поищите в кодовой базе или используйте Refactor > Rename Module.
  5. Обозначьте границы ответственности: модуль не должен содержать несвязанные слои (например UI + данные).

Пример имен: feature-cart, data-orders-remote, core-image-loader.

После переименования обязательно обновите include в settings.gradle(.kts) и зависимости в build.gradle(:app), иначе сборка сломается. В CI длинные имена могут добавить накладные расходы.

Автоматизация и валидация

  • Скрипт в buildSrc или Gradle task может валидировать имена (искать подчеркивания, точки, CamelCase).
  • Шаблоны модулей/templating в Android Studio ускоряют создание с нужным naming.
  • В settings.gradle.kts можно писать динамический include для feature-*, чтобы не забыть добавить модуль.

Пример проверки (Kotlin DSL, упрощённо): // в buildSrc tasks.register("validateModuleNames") { doLast { file("settings.gradle.kts").readLines().forEach { if (it.contains("_") || it.contains('.')) println("Найден некорректный символ в include: $it") } } }

Частые ошибки

  • Слишком общие имена: module1, lib2 — дают путаницу.
  • Длинные пути (>30 символов): в IDE и CI они обрезаются.
  • Смешение уровней: data+UI в одном модуле.
  • Неправильные зависимости: циклические импорты между модулями.

FAQ

  • Как назвать модуль с несколькими экранами одной фичи?
    • Группируйте: :feature:shopping с подмодулями cart, orders или объедините в один feature-shopping если связность высокая.
  • Можно ли использовать domain как нейтральное имя?
    • Да, domain или domain-user — хороший выбор для бизнес-логики; избегайте приставок архитектурных паттернов (например data-mvvm).
  • Что делать при массовом рефакторинге имён?
    • Проведите аудит, подготовьте скрипт для обновления include и CI, и протестируйте сборку на ветке.

Соблюдение простых правил именования делает проект предсказуемым, облегчает навигацию и поддержание, особенно при росте числа модулей до 50+. Начните с аудита current naming и внедрите валидацию в CI — это снизит ошибки при сборке и ускорит рефакторинг.