Modular monolith: boundaries inside one deploy
Checkout stays one app and one release, but its code is regrouped into cart, orders, payments and inventory modules — each with a public interface, private internals and its own tables, checked on every pull request. What makes the boundaries real, and when is that the place to stop rather than split?
15 minMediumStation: Modular monolithMembers lesson
Membership isn’t open yet. The free lessons are open — 18 of them.
- Monolith
- Modular monolith
- Service boundaries
- Microservices
What you'll be able to do
- 1Explain the rules that make a monolith modular — modules by business area, a public interface with private internals, each module owning its tables — and why each one matters.
- 2Predict which changes to Checkout break a module boundary — a query joining another module's table, a call into another module's internals — and what that costs when the module is later moved out.
- 3Choose between modularizing Checkout inside one deploy and splitting it into services, from team count, release pain and how settled the boundaries are.
Inside the lesson
- steps
- 12
- questions
- 12
- simulations
- 0
Step 1 · The setup
Back to Checkout, the one-app shop from the last stop. The team didn't split it. The code was too tangled to see where the cuts belonged, and splitting along tangled lines would only spread the mess across services. The Thursday waits still sting, but the tangle hurts more.
So they regroup it inside the one app instead. The code now sits in four parts by business area — cart, orders, payments and inventory (where the stock checks live). Still one codebase, one deploy, one release.
Six weeks later a pull request comes in. The cart page should show a "paid" badge next to each order. The quickest way: the cart code loads payments' own Charge records — payments' table class — and reads their status.
Steps 2–12 are for members