Clean Architecture .NET 10 Starter — MediatR, EF Core, Web API and Tests

A clean starting point for .NET 10 backends

Every new enterprise backend begins with the same hour of plumbing: projects, references, dependency injection, a database context, a first handler and a test harness. dotnet-clean-architecture-starter is that hour done once, done properly, and kept minimal on purpose — a production-ready Clean Architecture scaffold for .NET 10 that you can clone and start shaping into your domain.

Use it as a starter for a real service, or as a reference implementation for learning Clean Architecture, MediatR, EF Core and test patterns.

What's inside

• Domain-centric layout — Core, Application, Infrastructure and API projects, with dependencies pointing inward.
• MediatR for use-case orchestration — controllers send requests, handlers own the logic.
• EF Core with SQLite for zero-setup local development.
• Minimal, clear examples of a repository, a handler and a controller, wired end to end.
• Four test projects — unit and integration tests with xUnit, Moq, FluentAssertions and the EF Core InMemory provider.
• Bootstrap PowerShell scripts to scaffold the solution and tests quickly.

Solution layout

MySolution/
 ├─ src/
 │  ├─ MySolution.Core/            # Domain models, entities, interfaces
 │  ├─ MySolution.Application/     # Use cases, MediatR requests and handlers
 │  ├─ MySolution.Infrastructure/  # EF Core DbContext, repositories
 │  └─ MySolution.API/             # ASP.NET Core Web API, Program.cs, controllers
 └─ tests/
    ├─ MySolution.Core.Tests
    ├─ MySolution.Application.Tests
    ├─ MySolution.Infrastructure.Tests
    └─ MySolution.API.Tests

The API project is the composition root: it wires dependencies, while Application handlers depend only on repository interfaces defined in Core, and Infrastructure implements them. Swapping SQLite for SQL Server or PostgreSQL is a change to Program.cs and the AppDbContext configuration — nothing in the domain moves.

Testing that stays isolated

API integration tests use WebApplicationFactory with the in-memory EF provider, so each run starts from a known state. Give every test its own in-memory database name, or reset state between tests, to avoid cross-test interference.

# Run every test project
dotnet test

# Or just one
dotnet test tests/MySolution.Application.Tests

Quick start

Prerequisites: the .NET 10 SDK and Git. Docker and the dotnet-ef tool are optional.

git clone https://github.com/pravinharchandani/dotnet-clean-architecture-starter.git
cd dotnet-clean-architecture-starter

dotnet restore
dotnet build

# Optional: create and apply EF Core migrations
dotnet tool install --global dotnet-ef
dotnet ef migrations add Init -p src/MySolution.Infrastructure -s src/MySolution.API
dotnet ef database update -p src/MySolution.Infrastructure -s src/MySolution.API

# Run the API
dotnet run --project src/MySolution.API

In development, Swagger UI is served at http://localhost:5000/swagger (or the port shown in the console).

Built for teams

The layered layout maps cleanly onto ownership — domain, application, infrastructure and API can each have an owner and evolve independently. That makes the template a good fit for teams standardising how new services are started.

Recommended next steps

• Add DTOs and mapping with AutoMapper or Mapster.
• Add FluentValidation for request validation.
• Add Serilog for structured logging.
• Add health checks and metrics endpoints.
• Add a GitHub Actions pipeline that runs dotnet build and dotnet test.
• Containerise the API with a Dockerfile and add a deployment pipeline.

License

MIT — free to use for your own projects or as a reference. Contributions, issues and suggestions are welcome; include a clear description, the reason for the change and tests that prove it.