Modular monoliths in .NET

Why consider a modular monolith

Microservices add operational overhead: distributed tracing, deployment pipelines per service, network failure handling. For many products, especially early-stage or SMEs, a well-structured monolith is faster to ship and easier to maintain. The key is to structure it so you could extract modules later if needed.

Structuring modules

• Each module is a vertical slice: its own folder (or project), its own domain types, its own persistence if appropriate.
• Modules communicate via interfaces and events, not direct database access across boundaries.
• Use .NET's minimal APIs or feature folders within a single ASP.NET Core app to keep routing simple.

When to evolve

If a module grows too large, has different scaling needs, or is owned by a different team, that's the time to consider extraction. By then you'll have clear boundaries and a migration path. Don't start with microservices "because we might need them someday."