Why Modularize
Build speed, ownership and reuse.
The Monolith Problem
When an Android app grows, all its code often lives in a single app module. This is a monolith. At first it is convenient, but over time it becomes painful: every change touches the same module, builds get slow, and team members constantly step on each other.
Modularization means splitting that one big module into many smaller, focused Gradle modules. In this lesson you will learn why teams do this and what concrete benefits it brings.
What a Module Actually Is
In Gradle, a module is an independently buildable unit of code with its own build.gradle.kts file. Your app already has at least one: the :app module. You declare every module in settings.gradle.kts.
Adding a module is as simple as including it. Each module produces its own build output and can depend on other modules.
// settings.gradle.kts
include(":app")
include(":core:designsystem")
include(":core:data")
include(":feature:home")
include(":feature:profile")