Modular monolith

Modular monolith

A modular monolith is still deployed as one app, but its code is split into modules by business area — orders, payments, inventory — and each module keeps its internals private behind a public interface and owns its own tables. Other modules call that interface; they never reach into its code or its data. Tools check the rules on every change. You keep the simple single deploy and still get boundaries you could later turn into services.

Use when

A monolith whose teams keep stepping on each other's code but can still share one release · Domain boundaries that are still being discovered and need to stay cheap to move · Preparing a later split — a module with its own interface and data is easy to lift out

Avoid when

Parts that truly need their own release schedule, scaling or failure isolation — that's what a separate service is for · Without tooling or reviews that enforce the boundaries — the modules erode back into one tangle

Trade-offs

Keeps one deploy and in-process calls, but every team still ships on the shared release · Boundaries need tooling and discipline to stay real; an unchecked boundary decays · Calls through public interfaces are more work than reaching straight into another module's internals, and that friction is the point

Requires

Monolith