Monolith & Modular Monolith

A monolith can be well designed, and usually should be tried first. Internal module contracts, shared libraries, and the `common/` folder as a design failure.

Designing a Monolith

A monolith is a deployment decision, not a structural one. It can be well designed, it usually should be where a team starts, and conflating it with "big ball of mud" costs teams years.

Q · If a monolith is one deployable unit, what does good design inside it actually consist of?

The Modular Monolith

One deployment, several modules, each owning its domain logic, its interface and its data. The internal-boundary discipline of services without the operational bill.

Q · What has to be true of a module before "modular monolith" describes the codebase rather than the ambition?

Internal Module Contracts

Inside one deployment, the contract that matters is who may touch which data. Arbitrary cross-module table access is what makes a modular monolith aspirational rather than real.

Q · Inside a single process with a single database, what stops a module boundary from being a suggestion?

Shared Libraries

The internal package everyone depends on. Its fan-in is the point and also the problem: every change ripples outward to code you did not open.

Q · When should code be extracted into a shared internal library, and what does everyone depending on it actually cost?

The Common Module

`common/`, `shared/`, `utils/` — where code goes when nobody will own it. The cause is missing ownership, not laziness, and the fix has to address the cause.

Q · Why does every codebase grow a folder named for having no name, and what should go there instead?