Які проблеми вирішує модульна архітектура?
Monolith-застосунок з 50+ екранами, де все в одному модулі — це історія про те, як команда з 8 розробників чекає 4 хвилини повної збірки на кожну зміну, і як фіча однієї команди ламає тести іншої, тому що обидва імпортують один і той же singleton. Модульна архітектура вирішує конкретно ці проблеми. Ми допомагаємо командам модуляризувати застосунки від 20 до 200 екранів, спираючись на Apple Human Interface Guidelines та багаторічний досвід. Послуга модуляризації включає проектування модульної схеми, реалізацію core-модулів, міграцію фіч та налаштування збірки.
- Швидкість збірки. При зміні одного файлу в feature-модулі перезбирається тільки він. Модуляризація скорочує інкрементальну збірку в 3–5 разів — з 7–11 хвилин до 45–90 секунд (реальний кейс).
- Merge-конфлікти. Коли декілька команд працюють в одному
.pbxprojабоbuild.gradle, конфлікти неминучі. Модулі ізолюють код: feature-гілки рідко перетинаються. - Ізоляція тестів. Тести одного модуля не залежать від змін в іншому. Можна запускати тільки тести порушеного модуля.
Як ми це робимо: стек і практики
Розділення на модулі
Стандартний підхід — розділення за фічами з загальним шаром:
:app — точка входу, DI-граф, навігація :core:network — HTTP клієнт, interceptors :core:storage — БД, SharedPreferences/DataStore :core:ui — загальні компоненти, тема :core:auth — токени, AuthInterceptor :feature:profile — профіль користувача :feature:catalog — каталог товарів :feature:checkout — оформлення замовлення :feature:orders — історія замовлень Кожен :feature:* модуль залежить тільки від :core:* і не знає про інші фічі. Навігація між фічами — через абстракцію: NavigationManager в :core, яку кожна фіча використовує для переходу без прямого імпорту іншого feature-модуля. На Android — Navigation Component з NavGraph на рівні :app, deep links реєструються в маніфестах модулів. На iOS аналогічно — Coordinator pattern або Router з protocol-based навігацією.
Android. Кожен :feature:* — окремий Gradle-модуль (:feature:catalog → catalog/build.gradle.kts). Gradle Configuration Cache + Build Cache (~/.gradle/caches) радикально скорочують час перезбірки: змінюємо тільки :feature:checkout — перезбирається тільки він. --configuration-cache в Gradle 8 стабільний. Kapt → KSP: міграція annotation processor'ів з Kapt на KSP (Kotlin Symbol Processing) дає +30–50% до швидкості генерації коду.
iOS. Модулі реалізуються через Swift Package Manager (локальні) або як Framework targets в Xcode workspace. Swift Package Manager підтримує локальні пакети через path: в Package.swift. Workspace з декількома проектами (Feature1.xcodeproj, Feature2.xcodeproj) — застарілий підхід, новий — монорепо з локальними SPM пакетами + один основний .xcodeproj. Tuist або XcodeGen автогенерують .xcodeproj з конфігураційних файлів, що виключає merge-конфлікти в .pbxproj.
DI в модульній архітектурі
DI-граф не повинен бути монолітним. На Android — Hilt з @InstallIn(SingletonComponent::class) для core-залежностей та @InstallIn(ViewModelComponent::class) для feature-специфічних. Кожен feature-модуль оголошує свої @Module-класи, Hilt збирає граф у compile time. Це означає: якщо :feature:catalog не підключений в :app — його DI-модуль не компілюється і не впливає на збірку.
На iOS — ручний DI через Resolver/Swinject, або чистий factory-патерн без DI-фреймворку. В модульному застосунку DI-фреймворк на Swift менш критичний: залежності передаються через ініціалізатори, а Composition Root в :app збирає все разом.
Чому модульна архітектура краща за моноліт?
Модульний застосунок економить до 40% бюджету на розробку в довгостроковій перспективі (за даними нашого досвіду). Порівняйте: в моноліті одна помилка в shared-коді може паралізувати всю команду на день, а в модульному застосунку проблема локалізована. Google I/O демонстрував, що Play Feature Delivery дозволяє скоротити розмір базового APK на 30–50%.
Dynamic Delivery та опціональні модулі
Android дозволяє доставляти feature-модулі на вимогу через Play Feature Delivery (колишній Dynamic Delivery). Користувач завантажує базовий застосунок, важкі фічі (AR-примірка, офлайн-карти) — при першому зверненні. SplitInstallManager керує завантаженням, SplitCompatActivity — активація. На iOS аналога немає — App Clips закривають іншу нішу.
| Порівняння | Моноліт (одна команда) | Модульне (6 команд) |
|---|---|---|
| Час повної збірки Android | 7 хвилин | 4 хвилини (з Build Cache) |
| Перезбірка одного модуля | 7 хвилин | 45–90 секунд |
| Merge-конфліктів на місяць | 15–20 | 2–5 |
| Можливість паралельної роботи | Обмежена | Повна |
Кейс. Рітейл-застосунок: 6 команд, 80+ екранів, Android + iOS. До модуляризації: повна збірка Android — 7 хвилин, iOS — 11 хвилин. Після розбивки на 14 модулів з налаштованим Build Cache: інкрементальна збірка при зміні одного feature-модуля — 45–90 секунд. Merge-конфлікти в загальному коді знизилися приблизно втричі. Паралельна розробка фіч без блокувань між командами. Економія часу розробки оцінюється в 30–50% на довгій дистанції. Середній бюджет модуляризації для проекту такого розміру визначається після аудиту.
Що входить в роботу?
| Deliverable | Опис |
|---|---|
| Аудит архітектури | Аналіз поточної кодової бази, виявлення залежностей, циклічних посилань, вузьких місць збірки |
| Проектування модульної схеми | Діаграма модулів, інтерфейси, roadmap міграції |
| Реалізація core-модулів | Створення сітки core-шарів (network, storage, ui, auth) |
| Міграція фіч | Кожна фіча виділяється в свій модуль зі збереженням працездатності |
| Налаштування збірки | Build Cache, Configuration Cache, CI/CD інкрементальна збірка |
| Документація | README модулів, схема навігації, конвенції іменування |
| Навчання команди | Воркшопи з модульної розробки, код-рев'ю на перших етапах |
| Підтримка на старті | 2–4 тижні пост-релізної підтримки, виправлення неузгодженостей |
Як проходить модуляризація: покроково
- Аналіз поточної архітектури — виявлення залежностей та циклів.
- Проектування модульної схеми — діаграма модулів та інтерфейсів.
- Реалізація core-модулів — сітка core-шарів (network, storage, ui).
- Міграція фіч — кожна фіча виділяється в свій модуль.
- Налаштування збірки — Build Cache, Configuration Cache, CI/CD.
- Тестування та документування — тести модулів, схема навігації, README.
- Підтримка та навчання команди — код-рев'ю, воркшопи з модульної розробки.
Терміни та вартість
| Розмір проекту | Орієнтовні терміни |
|---|---|
| 20–40 екранів, 1–2 команди | 4–8 тижнів |
| 50–100 екранів, 3–5 команд | 2–4 місяці |
| 100+ екранів, складні залежності | 4–8 місяців |
Вартість розраховується індивідуально після аудиту архітектури та залежностей існуючого коду. Замовте аудит — ми оцінимо ваш проект і запропонуємо оптимальний план модуляризації. Зателефонуйте або напишіть нам, щоб обговорити деталі. Дізнайтеся, як модуляризація може прискорити вашу розробку, — отримайте консультацію сьогодні.
Типові помилки при самостійній модуляризації
Circular dependencies. :feature:profile імпортує :feature:orders, :feature:orders імпортує :feature:profile. Gradle не збере — circular dependency. Рішення: винести загальні моделі в :core:domain або :shared:models, обидві фічі залежать тільки від нього.
Занадто дрібні модулі. :core:extensions з 5 extension-функціями — overhead без вигоди. Раціональний мінімум: модуль виправданий, якщо його можна міняти незалежно і він не залежить від модулів, які міняються частіше.
Resource ID конфлікти. На Android при об'єднанні ресурсів декількох модулів виникають колізії імен. Конвенція: префікс модуля для всіх ресурсів (catalog_item_card_background, не просто item_card_background). R class isolation через android.nonTransitiveRClass=true в gradle.properties — обов'язковий для великих проектів.
Чому варто довірити модуляризацію професіоналам?
Ми маємо більше 7 років досвіду в мобільній розробці та реалізували більше 30 проектів з модульною архітектурою. Гарантуємо плавний перехід без простоїв команди. Сертифікати Apple Developer та Google Associate Android Developer підтверджують нашу кваліфікацію. Зв'яжіться з нами для консультації — допоможемо вам прискорити розробку та знизити cost of change.