C# Backend

Quick Reference

• Start by defining boundary: API, application service, domain logic, infrastructure, or background worker.
• Select runtime profile early: controller API, minimal API, background worker, or mixed host.
• For systems with evolving domain boundaries, prefer modular architecture over premature service splits.
• Apply C# language rules first: clarity, nullability, immutability, explicit failures, cancellation-aware async.
• Keep dependency direction inward and keep I/O at boundaries.
• Choose persistence per use case: Dapper for query-heavy SQL paths, EF Core for aggregate-heavy relational writes, Mongo for document-first modules.
• Treat reliability, observability, and security as default behavior, not follow-up work.
• Use iterative quality loop: code -> build -> run tests -> fix -> repeat.
• If deep controller/CQRS endpoint design is required, switch to $csharp-api-cqrs and use its MediatR + FluentResults handler template.
• If the task is primarily NUnit fixture design, WireMock/Testcontainers setup, or flake reduction, switch to $qa-testing-nunit.
• If the task is primarily nuke/Build.cs, CI target sequencing, or artifact publication, switch to $ops-nuke-cicd.
• If the task is primarily legacy ILogger or Serilog rewrite automation, switch to $dev-structured-logs.

Workflow

1. Classify the requested change (new feature, refactor, bug fix, review).
2. Choose runtime shape before implementation details.