ModularMonolith
A monolith with enforced internal module boundaries — a middle ground that keeps deploy simplicity but prepares for extraction.
Why we need this / what value this brings
Gets most of microservices' organizational clarity (clear ownership boundaries) without the operational cost (network calls, distributed data, service discovery).
When to use this
When a monolith's internal coupling is starting to cause friction (changes in one area breaking unrelated areas) but the team is still too small for separate services.
How to use or implement this
Enforce module boundaries with folder structure and dependency-direction rules (e.g. lint rules blocking cross-module imports of internals), even though it all deploys as one unit.
Research questions
- What makes a module boundary 'enforced' in practice (separate packages, dependency-direction linting)?
Empty folder — drop notes, links, and findings here as you research.