Modularity separates a system into parts that teams can understand and change without routinely disrupting unrelated work. Its value becomes clear when a growing system slows compilation, testing, deployment, and onboarding—and when changes in one area break another. Looser coupling and ownership of system parts can help restore the ability to innovate. section 10.4
A category system under strain
Vinted’s marketplace expanded beyond women’s clothing into six departments. Its category tree needed to grow deeper and wider, but the existing architecture blocked a newly formed categories team from delivering value. Engineering leaders agreed that a loosely coupled, modular architecture, paired with teams owning parts of the system, was needed. section 10.4
Team boundaries and software boundaries may not change at the same pace. During a phased transition, teams can still share technical artifacts and need closer collaboration. At CloudSuite, a backend API crossed team boundaries; because physically separating it required considerable effort, collaboration and modularization within the component came first. section 17.4
The first-phase diagram shows why reorganizing teams does not immediately remove dependencies in the existing architecture. section 17.4









