A monolithic application deploys its major functionality as one unit. That can become a constraint when changes across different business areas must move through the same codebase or deployment. The question is not whether a monolith is inherently wrong, but whether its boundaries still support the organization’s goals. section 9.3.4 section 10.4
An airline’s modernization starting point
A large airline’s tightly entangled monolith was risky to change: every change required deploying the whole system, and reliability suffered on peak-traffic days. To decide where to start, stakeholders used EventStorming to examine the current state and identify domains and subdomains. They considered both where teams could work independently and where related concerns still needed coordination. section 9.3.4
Growth inside a shared codebase
At Vinted, expansion beyond women’s clothing exposed assumptions built into a monolithic codebase. As the engineering organization grew, features took longer to deliver, onboarding slowed, and changes began breaking unrelated functionality. Engineering leaders agreed on a more loosely coupled, modular architecture with teams owning parts of the system. section 10.4
Acquisition creates a different pressure: several legacy monoliths, built with different stacks and expectations, may be asked to provide one coherent customer experience. Integration then becomes a question about products, domain boundaries, software, and teams—not just connecting systems. A practical first step is to map those boundaries with stakeholders before deciding how the architecture should evolve. section 3.1.4 section 9.3.4
