Modular monolith and plugin architecture
A modular monolith keeps strong in-process operational simplicity while enforcing business modules. It is often the best default when distribution has no proven benefit.
Core ideas and patterns
| Idea | What it solves | Cost, limit, or warning |
|---|---|---|
| Modular monolith | Combines one deployment with explicit modules | Boundaries need automated enforcement |
| Plugin/microkernel | Extends a stable core through contracts | Versioning and trust of plugins become platform concerns |
| Package by feature | Keeps a business slice together | Shared technical packages can recreate horizontal coupling |
| Internal API | Limits what one module can call | Language visibility alone may be insufficient |
| Module-owned schema | Assigns table ownership inside one database | Database permissions and migration discipline are needed |
| In-process event | Decouples modules without a broker | Transaction and ordering semantics must be explicit |
How to apply it
Define modules from domains and change boundaries. Give each module an API, data ownership, tests, and owner. Ban direct access to internals and foreign tables. Use in-process calls for immediate consistency and events for notification. Extract a service only when evidence shows independent scaling, failure isolation, deployment, or governance value.
Evidence, not opinion
Run architecture tests for module dependencies, migration ownership, cyclic calls, and forbidden imports. Measure build/release lead time, incident blast radius, and cross-module changes.
Small example
A commerce monolith contains Catalog, Pricing, Basket, Ordering, Inventory, and Fulfillment modules. Ordering requests inventory through its API; it never joins inventory tables directly.
Feynman check
Explain the design to a new engineer without using the pattern names. State the problem, the forces that conflict, the chosen boundary or mechanism, what can fail, and the evidence that would prove the choice still works.