Forging the path from monolith to multi-module app
summary
A year-long migration breaks the TIER Android monolith into a shell, libraries, feature contracts and feature implementations layout, extracts the ride feature first, and enforces boundaries with a small Gradle plugin that fails bad builds. Navigation uses explicit contract functions plus a router pattern and a single-event relay to return results and embed fragments. Tooling changes include moving versions to a Gradle version catalog, centralizing config in buildSrc and generating modules with cookiecutter; build parallelism and developer ownership noticeably improve.
AI-written summary · about
chapters (27)
- 0:00Introduction to journey
- 1:31Why modularize the monolith
- 3:39Modular architecture overview
- 5:06Shell and library layers
- 6:51Feature module structure
- 8:36Contract-based decoupling
- 10:26App module and legacy code
- 13:14Enforcing structure with Gradle
- 13:58Choosing the first feature
- 15:04Dependency analysis process
- 16:08Extracting the first module
- 17:12UI feature modularization challenges
- 19:19Navigation between modules
- 21:50Handling results and fragments
- 23:16Router pattern for navigation
- 24:44Internal router implementation
- 27:12Manual navigation trade-offs
- 27:53Gradle version catalogs
- 28:34Build configuration management
- 29:38Automating module templates
- 30:24Celebrating small wins
- 31:06Tooling and testing modules
- 31:51One year of preparation
- 33:16Key lessons and advice
- 34:44Avoid refactoring while modularizing
- 35:49Discovering hidden issues
- 36:11Closing and resources
related talks
39mForging the path from monolith to multi-module app
38mForging the path from monolith to multi-module app
30mModular Android Development
32mRoad to modularization
40mModularizing Android Applications
40mScaling Android Apps
39mModule Mayhem: Tales From Shared Business Logic
46mFrom Chaos to Cohesion: Building Modular Monoliths in the Real World