Module Mayhem: Tales From Shared Business Logic
summary
Peloton migrates from two modules to 2 to 2,000 modules to cut build bottlenecks that once caused 30+ minute builds, using Gradle, DTOs and utility modules as the first extracts. A privacy‑settings feature is implemented as a reusable module with Compose UI and even a shared view model to hit a legal deadline; it ships and prevents compliance failures, but creates heavier Gradle syncing, ownership friction and CI dependency‑graph work.
AI-written summary · about
chapters (14)
- 0:00Module mayhem intro
- 1:49Speaker background
- 3:54Why Peloton adopted multimodule projects
- 8:06Build time issues
- 10:11Cross-module resources
- 13:18Multiplatform support
- 15:03From two to two thousand modules
- 17:09Convincing leadership
- 19:55Early modular pains
- 22:00Shared business logic tales
- 26:16Balancing shared logic
- 30:29Cross-team features
- 32:54Shared modules pros/cons
- 36:21Key takeaways
related talks
37mA Complete Journey of Android Modularisation
46mFrom Chaos to Cohesion: Building Modular Monoliths in the Real World
38mForging the path from monolith to multi-module app
37mForging the path from monolith to multi-module app
39mForging the path from monolith to multi-module app
30mModular Android Development
32mRoad to modularization
40mModularizing Android Applications