The pragmatic middle path most teams should have taken first.
Keep one deployment, create boundaries
A modular monolith preserves a single application deployment while separating business capabilities inside the codebase. It can reduce coupling without introducing the operational cost of distributed services.
Modules should own their data and expose intentional interfaces. Direct access across boundaries is convenient at first but recreates the original coupling.
Migrate by pressure
Identify areas where change repeatedly causes conflicts or regressions. Extract one boundary at a time, add contract tests and move dependencies behind the new interface.
Do not reorganise only by technical layer. Modules work best when they represent business capabilities with clear ownership.
Know when distribution is justified
Separate deployment becomes useful when a capability needs independent scaling, release timing, isolation or ownership. Until those pressures are real, process boundaries add network failure, observability and consistency work.
A good modular monolith keeps that future option open while remaining simple to run today.