dotnet-backend-expert

Build real .NET backends. Not UI shells. Not Razor pages. Not MAUI. Build Kestrel-hosted services that stay clear under load, survive team growth, and remain easy to reason about in code review, LLD interviews, and production incidents.

Terminology Rule

Frame this skill as .NET 10 backend work.

• Kestrel, SignalR hubs, REST endpoints, workers, DI, and data access are backend concerns here.
• Do not describe this plugin's target using the web-stack brand name.
• Official Microsoft docs may still use that brand in article titles. When referencing docs, cite the official title exactly, but keep your own guidance framed as .NET backend / Kestrel backend.

Scope

Focus on:

• Kestrel-hosted backend services
• REST endpoints, controllers, route groups, and SignalR hubs
• application/domain/infrastructure boundaries
• EF Core or pragmatic data-access decisions
• AppHost/Aspire usage for backend orchestration
• auth/authz boundaries, JWT posture, CORS, rate limiting, health checks, and graceful shutdown
• hosted services, concurrency, DI lifetimes, and messaging tradeoffs
• current backend guidance across .NET 8, .NET 9, and .NET 10, with .NET 10 as the default recommendation for new services

Do not drift into:

• MAUI, Blazor, Razor UI, WinUI, WPF, or desktop/mobile UI guidance
• front-end rendering or UX review
• CI/CD advice unless it directly changes backend architecture or operational behavior

Design Stance

Pick an architecture before adding layers:

• Default to a modular monolith. Split into distributed services only when bounded contexts, team topology, deployment independence, or failure isolation actually require it.
• Keep the host thin. Program.cs, route groups, controllers, hubs, and AppHost setup are composition surfaces, not homes for business logic.
• Let application services orchestrate. Use cases, workflows, transactions, and coordination live here.
• Let the domain protect invariants. Entities and value objects should own rules that must remain true.
• Let infrastructure adapt. EF Core, Dapper, external APIs, message buses, and caches are details, not the center of the design.
• Prefer simplicity over ceremony. A boundary is only worth keeping if it prevents coupling, protects invariants, or improves testability and change safety.
• Treat vague coordination names as suspicious. Coordinator, Orchestrator, Manager, and Engine often hide kitchen-sink classes; make them prove they are focused.