27.3 What is a modular monolith?

In the restaurant: Still one kitchen and one front door, but the tandoor, curry and dessert stations each have their own space and their own shelf. You can ask another station for something, through the pass, but you can't just grab from their shelf.

In the system: A modular monolith is deployed as one unit but organised into modules with enforced boundaries:

• Each module (catalogue, cart, orders, payments) has a clear public interface; everything else is private.
• Modules depend on each other only in declared directions (orders may use catalogue; catalogue may not use orders).
• Each module owns its tables; others go through its interface, not straight into its data.
• Boundaries are checked by tools, not just goodwill. In the chapter's code, a checker flags cart → payments and catalog → orders as undeclared dependencies.

Shopify took this path: rather than adopt microservices, it kept one codebase and deployment but defined and enforced boundaries between components, keeping a single test and deploy pipeline while gaining modularity.

Why it's often the best next step:

• You get most of the code benefits of services (clear ownership, less coupling) without the network costs.
• Good modules are easy to extract later if one really needs to be a separate service: the boundary already exists.

Memory code: "One kitchen, but every station guards its own shelf."

---