.NET 10 is a strong platform for SaaS in 2026. The performance story is excellent, the tooling is mature, and the ecosystem has caught up with the rest of the industry on most fronts. The harder questions are architectural — the ones that don't have obvious right answers but that you'll live with for years.
Clean architecture in practice
We use a layered approach: Domain (entities, value objects, domain events), Application (use cases, command/query handlers via MediatR), Infrastructure (EF Core, external services), and API (controllers, minimal API endpoints). The rule is simple: dependencies only point inward. Domain knows nothing about EF Core. Application knows nothing about HTTP.
Project structure
src/
Domain/ # Entities, value objects, domain events
Application/ # Commands, queries, handlers, interfaces
Infrastructure/ # EF Core, email, storage, external APIs
Api/ # Controllers, middleware, DI registration
tests/
Unit/ # Domain logic, pure functions
Integration/ # Database, external service integration
Architecture/ # ArchUnit tests — enforce layer boundariesWhy architecture tests matter
Architecture decisions decay over time unless they're enforced. We use NetArchTest to write tests that verify the rules — Application doesn't reference Infrastructure, Domain doesn't reference anything outside itself. These tests run in CI and fail the build if a dependency boundary is crossed. The architecture stays clean by default.
Decisions we make consistently
- —MediatR for command/query dispatch — keeps handlers focused and testable
- —FluentValidation for input validation — co-located with commands
- —Result<T> pattern instead of exceptions for expected failures
- —EF Core with explicit configurations — no convention magic in production code
- —Minimal API for performance-critical endpoints, controllers for complex routing
None of these are novel. They're the choices that have survived contact with real production systems and real teams, which is the only test that matters.