.NET Enterprise Architecture in 2026 has settled on a middle path between the mega-project monolith and the premature microservices split: the modular monolith. The idea is simple — one deployable process, one database, but with the code organized into modules that respect the same discipline you would demand from separate services. Domain boundaries are drawn in code rather than in infrastructure. This article shows how to draw those boundaries well on .NET 10 and when the discipline genuinely pays off.
Why Modular Monoliths Anchor Modern .NET Enterprise Architecture
The modular monolith is attractive because it attacks the two costs that sink enterprise projects: the cost of coupling and the cost of operations. A layered monolith without boundaries eventually becomes a ball of mud, while a microservice architecture introduces distributed transactions, network failures, and deployment orchestration long before the business needs them. The modular monolith keeps the operational simplicity of one process and uses code structure to hold the line between modules.
In practice this delivers measurable benefits for a typical product team:
- One build, one deployable, one set of health checks — no orchestration ceremony
- Strict module boundaries that are enforced by the compiler and unit tests
- Domain events as the only cross-module communication path
- A clear extraction path: any module is a candidate to become a service later
- Feature development that stays fast because teams rarely touch the same module
Every Indotalent product is a modular monolith of this kind: one .NET 10 project, feature folders per module, and Blazor Server screens that call the same handlers the REST API exposes.
Drawing .NET Enterprise Architecture Domain Boundaries in a Single Process
The first question is where the boundaries go. A useful heuristic is to look for words your business uses in different senses in different contexts. An order means something different to Sales than it does to Warehouse. An employee means something different to Payroll than to Facilities. Wherever the same noun means different things, you have a boundary worth drawing.
Once the modules are named — Orders, Inventory, Invoicing, Reporting — each one owns its entities, its handlers, and its database tables. Other modules never touch those tables directly. When Inventory must know that an order was placed, Orders publishes a domain event and Inventory reacts:
public sealed class OrderPlacedEvent : INotification
{
public Guid OrderId { get; init; }
public Guid ProductId { get; init; }
public int Quantity { get; init; }
}
public sealed class ReserveStockOnOrderPlaced
: INotificationHandler<OrderPlacedEvent>
{
private readonly IStockService _stock;
public ReserveStockOnOrderPlaced(IStockService stock) => _stock = stock;
public async Task Handle(OrderPlacedEvent e, CancellationToken ct)
=> await _stock.ReserveAsync(e.ProductId, e.Quantity, ct);
}The Orders module does not know Inventory exists. It raises an event through MediatR, and the handler in the Inventory module reacts. If Inventory is later extracted into its own service, the Orders module changes nothing — the event simply travels over a queue instead of in-process. That is the entire point of a domain boundary: the communication contract survives the split.
Sharing Data Across Modules Safely
Inside a modular monolith the temptation is to share the DbContext and reach across modules "because it is just one database." Resist it. The boundary exists to keep modules independently evolvable, and every shared table erodes that independence. The rules that keep a modular monolith honest are few and enforceable:
- One DbContext owns the whole schema, but each module only accesses its own entity types
- Cross-module reads go through a query handler that belongs to the owning module
- Cross-module writes happen only in response to a domain event, never by importing another module's handler
- Shared infrastructure — audit interceptor, tenant filter, JWT policies — lives in one place everyone references
These rules are checkable. A test can walk the assembly and fail if a handler in the Inventory namespace reaches into entity types owned by Orders. When the test suite enforces the boundaries, the boundaries survive every refactor and every new hire.
When the Monolith Should Split
The modular monolith is not a stopping point; it is a starting point that makes a later split boring. Extract a module when one of three things is true: the module needs its own deploy cadence because it changes weekly while the rest changes monthly; the module needs to scale independently because it carries a disproportionate load; or a team boundary forms — two teams working in the same module collide constantly. When one of those is real, the extraction is mechanical because the boundaries already exist. The event stays the same, the handlers move to a new service, and the database table moves with its owner.
Until one of those triggers fires, resist the split. Distributed systems trade a monolith's simple problems for a network's complex ones: retries, sagas, versioned contracts, and observability across hops. A modular monolith gets you most of the architectural benefit at a tenth of the operational cost — which is why it is the honest default for .NET Enterprise Architecture in 2026.
FAQ
Is a modular monolith the same as just having good folders? No. Good folders help, but a modular monolith also enforces the boundaries — entities are owned per module, cross-module communication goes through domain events, and tests check the rules. The enforcement is what makes it an architecture instead of an arrangement.
Do modules in a monolith share one database? Usually yes, and that is fine. What matters is that each module owns its tables and no other module writes to them directly. The schema is one database; the ownership is strictly divided.
Can a modular monolith be converted to microservices later? Yes, and that is its main selling point. Because modules communicate through domain events and never share internals, extracting one module into a service is a mechanical exercise rather than a rewrite.
What is the difference between domain events and CQRS? Domain events are notifications about something that happened — an order was placed — published so other modules can react. CQRS separates commands from queries. Both work together in a modular monolith: commands change state and raise events, queries read state.
Key Takeaways
- A modular monolith is one deployable with strict, code-enforced domain boundaries
- Draw boundaries where business nouns change meaning between contexts
- Domain events are the only cross-module communication path
- Tests should enforce the boundary rules so they survive refactors
- Split into services only for cadence, scaling, or team ownership reasons
- Indotalent products are complete .NET 10 modular monoliths demonstrating this design — $21 each