Create boundaries that make change cheap: high cohesion inside, low coupling outside
Most architecture pain comes from one thing: unclear boundaries. When everything can call everything, change becomes expensive.
Your goal: high cohesion, low coupling.
A modular monolith is a single deployable app with clear internal boundaries. It gives you most benefits of microservices without the operational overhead.
When it’s ideal:
Boundary techniques:
Ask: “Where will change happen most often?” Put boundaries around those hotspots.
Examples:
Q: Why is a modular monolith often safer than microservices for small teams?
<details> <summary>💡 Reveal Answer</summary>Because it preserves clear boundaries without adding distributed complexity: network calls, observability, deployment coordination, and consistency challenges. For small teams, the operational cost of microservices often outweighs their benefits.
</details>Full access
Unlock all 12 lessons, templates, and resources for Software Architecture & Decision Patterns. Free.
Map one system’s boundaries:
Scenario: Two teams share the same “Users” table. Team A needs rapid changes; Team B needs stability for compliance.
What’s the best next move?
Create a clear ownership boundary. One team owns the canonical user data, and the other consumes it via a stable API or event stream. If needed, introduce a read‑model or replica to separate change velocity from compliance stability.
| Idea | Remember This |
|---|---|
| Boundaries | Architecture is mostly about clear module boundaries |
| Modular monolith | Best default for most teams |
| Coupling smells | Shared DB and circular deps are red flags |
| Design for change | Isolate the areas that churn |
Next: Data Architecture Decisions