11 practical guides
Build a single deployable application with explicit module boundaries. These guides cover how to choose those boundaries, let modules communicate, isolate their data, and decide when a module is ready to become a separate service.
Start here
A modular monolith keeps one deployment while enforcing business boundaries inside the codebase. This guide connects module design, data isolation, communication, testing, and the evidence that can justify extracting a service later.
Read the complete guide →Draw module boundaries wrong and you fight your own architecture on every feature. Bounded contexts give you a systematic way to draw them: map business capabilities, give each module its own language and data, and validate with the change test. Plus the three boundary mistakes that sink most modular monoliths.
The Ordering module publishes an event, and Shipping and Notifications react without the publisher knowing they exist. The catch: an in-process event bus runs every handler synchronously in the caller's scope, so a slow or failing consumer becomes the publisher's problem. Here is the full setup, and the point where the outbox pattern has to take over.
Build a working Modular Monolith skeleton in .NET: three modules, each with its own schema and DbContext, cross-module calls that go through Contracts projects only, and an in-process event bus. Architecture tests fail the build the moment someone crosses a boundary.
Placing an order touches Ordering, Inventory, Payment, and Shipping, and any step can fail after the previous ones already committed. The saga pattern breaks the process into local transactions with compensating actions, coordinated by an orchestrator that fits in one class. Here is how to build one inside a modular monolith, without a distributed transaction in sight.
Schema-per-module and database-per-module both enforce module boundaries at the data layer, but they differ sharply on transactions, operations, and your path to microservices. Here is the EF Core setup for both, the five trade-offs that actually matter, and the triggers that tell you when to graduate from schemas to separate databases.
Modules need to share some code without becoming coupled. The shared kernel pattern defines a small, explicit set of shared types that all modules can depend on.
Big-bang rewrites fail for predictable reasons: they take longer than planned, the legacy system keeps changing underneath them, and the business sees nothing until the end. The Strangler Fig pattern replaces a legacy monolith one bounded context at a time, with feature-flag routing, data sync, and a parallel run before every cutover. The system stays fully functional throughout.
Extract a module too early and you lock unstable boundaries into network contracts. Wait too long and extraction becomes a multi-month rewrite. These are the four concrete drivers that justify extracting a module into a microservice, the readiness checklist to pass first, and the extraction process that keeps a rollback path open.
The dual-write problem silently corrupts distributed systems. The Outbox pattern eliminates it by turning two unreliable writes into one atomic operation.
A modular monolith keeps one deployment while enforcing business boundaries inside the codebase. This guide connects module design, data isolation, communication, testing, and the evidence that can justify extracting a service later.
Modular Monoliths give you most of microservices benefits - loose coupling, independent modules, clear boundaries - without the operational complexity. Here is a practical comparison to help you decide which fits your project.
