A modular monolith is a software architecture pattern that structures a single deployable application into well-defined, loosely coupled internal modules with enforced boundaries. Unlike traditional monoliths where code gradually becomes entangled, and unlike microservices that distribute complexity across the network, modular monoliths deliver logical separation with operational simplicity: one codebase, one deployment, one database (optionally schema-isolated), but clear domain boundaries enforced through tooling, package visibility, and architectural tests. This pattern is experiencing a renaissance in 2026 — with teams at Amazon Prime Video, Shopify, and others moving back from microservices — because it provides the organizational clarity of distributed systems without the operational overhead, making it the pragmatic default for most teams until scale truly demands distribution. The key insight: modularity is a design discipline, not a deployment strategy — you can achieve clean boundaries and independent evolution paths while keeping everything in-process, then extract modules to services later if needed.
What This Cheat Sheet Covers
This topic spans 15 focused tables and 104 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: Core Architectural Concepts
| Concept | Example | Description |
|---|---|---|
Single deployable unit with Shipments/, Orders/, Payments/ modules | • Single process application internally organized into distinct modules with clear boundaries • each module owns its domain and exposes a public API • deployed as one artifact but designed for future extraction | |
Orders module with internal domain logic + public interfaces | • Self-contained unit encapsulating domain logic, data access, and API contracts • communicates with other modules only through defined interfaces or events • independently testable | |
Orders cannot directly access Payments database schemas | • Explicit separation enforced through package visibility (internal keyword in .NET), architectural tests (ArchUnit), or folder structure• prevents accidental coupling between modules | |
IOrderService interface in Orders.Contracts assembly | • Stable contract exposed by a module for external consumption • typically interfaces or DTOs in a separate assembly • hides implementation details and enables versioning | |
OrderRepository marked internal in .NET | • Implementation details not exposed outside the module • uses language visibility modifiers or package-private access • prevents direct database or service layer access from other modules |