Modularization
BUILD & TOOLING › Gradle
Splitting an Android codebase into loosely coupled Gradle modules with enforced boundaries.
Modularization is a staple system-design question for senior Android roles because it tests how you reason about build performance, ownership, and architectural boundaries at scale. Interviewers probe whether you can justify module types, defend dependency direction, and explain how navigation and DI cross module lines. Expect to discuss api vs implementation, avoiding feature-to-feature coupling, and the real trade-offs of over-modularizing.
What this covers
- Why modularize: faster incremental builds, clear ownership, enforced boundaries, reusability, and Play Feature Delivery
- Module types and roles: :app (entry/DI/root nav), :feature (UI+ViewModel per screen), :core/:data (repositories, shared utilities)
- Dependency direction rules: app to feature to data to core; features must not depend on other features
- Gradle api vs implementation and why implementation is the default for build speed and encapsulation
- Cross-module navigation by passing primitive IDs, and Hilt DI wiring across module boundaries
- Trade-offs of over- and under-modularization, plus high cohesion / low coupling and dependency inversion
Study this topic
- Modularization explained: the guided lesson
- 14 practice quiz questions
- 9 revision flashcards
- Modularization interview questions and answers