A team adopts a modular monolith. What must they do forever, and what happens if they stop?
Show the full answer Hide the answer
What is being tested
Whether you know the honest ongoing cost of the pattern rather than only its benefits.
What must be done forever
Enforce the boundaries in CI.
Nothing physically stops a developer from importing across a module boundary or writing a query that joins another module's tables. In a microservices architecture the network enforces it; in a monolith only tooling does.
Concretely: a build-time check on import graphs, and a check that no module queries another module's tables. Both fail the build.
What happens if they stop
It decays into a plain monolith, gradually and invisibly. One urgent change reaches across a boundary; the next developer sees it and follows the precedent; within a year the modules are nominal and the code is a tangle.
The decay is not noticed because nothing breaks — it simply becomes progressively harder to change, and by the time it is obvious, the boundaries would have to be re-established from scratch against far more code.
What the pattern buys
It separates module boundaries from process boundaries. Most arguments for microservices are really arguments for boundaries, and boundaries do not require a network in the middle.
Kept: real transactions; refactoring across a boundary with a compiler checking you; one stack trace per request; local calls that cannot time out; one deployment to reason about.
Given up: independent deployment and scaling, a single runtime failure domain, one technology stack.
Why the enforcement is worth it
Because the boundaries are the valuable part. A modular monolith with enforced boundaries can be split later, cheaply, when a forcing reason appears — a different resource profile, availability class or compliance boundary.
One that has decayed cannot, and the extraction becomes the multi-quarter project the pattern was meant to avoid.
What a strong answer adds
That this is the same discipline as any fitness function: an architectural decision that is not enforced by a build is a preference, and preferences erode. The check is the durable form of the decision.