A starting point for Clean Architecture with ASP.NET Core. Clean Architecture is just the latest in a series of names for the same loosely-coupled, dependency-inverted architecture. You will also find it named hexagonal, ports-and-adapters, or onion architecture.
Learn more about Clean Architecture and this template in NimblePros' Introducing Clean Architecture course. Use code ARDALIS to save 20%.
This architecture is used in the DDD Fundamentals course by Steve Smith and Julie Lerman.
🏫 Contact Steve's company, NimblePros, for Clean Architecture or DDD training and/or implementation assistance for your team.
Learn about how to implement Clean Architecture from NimblePros trainers Sarah "sadukie" Dutkiewicz and Steve "ardalis" Smith.
If you like or are using this project to learn or start your solution, please give it a star. Thanks!
Or if you're feeling really generous, we now support GitHub sponsorships - see the button above.
I'm please to announce that Amazon AWS's FOSS fund has chosen to award a 12-month sponsorship to this project. Thank you, and thanks to all of my other past and current sponsors!
By default the site uses HTTPS and expects you to have a self-signed developer certificate for localhost use. If you get an error with Chrome see this answer for mitigation instructions.
The main branch is now using .NET 9. This corresponds with NuGet package version 10.x. Previous versions are available - see our Releases.
- Live Stream Recordings Working on Clean Architecture
- DotNetRocks Podcast Discussion with Steve "ardalis" Smith
- Fritz and Friends Streaming Discussion with Steve "ardalis" Smith
To use this template, there are a few options:
- Install using
dotnet new(recommended) - Download this Repository (and modify as needed)
First, install the template from NuGet (https://www.nuget.org/packages/Ardalis.CleanArchitecture.Template/):
dotnet new install Ardalis.CleanArchitecture.TemplateYou can see available options by running the command with the -? option:
dotnet new clean-arch -?
ASP.NET Clean Architecture Solution (C#)
Author: Steve Smith @ardalis, Erik Dahl
Usage:
dotnet new clean-arch [options] [template options]
Options:
-n, --name <name> The name for the output being created. If no name is specified, the name of the output
directory is used.
-o, --output <output> Location to place the generated output.
--dry-run Displays a summary of what would happen if the given command line were run if it would result
in a template creation.
--force Forces content to be generated even if it would change existing files.
--no-update-check Disables checking for the template package updates when instantiating a template.
--project <project> The project that should be used for context evaluation.
-lang, --language <C#> Specifies the template language to instantiate.
--type <project> Specifies the template type to instantiate.
Template options:
-as, --aspire Include .NET Aspire.
Type: bool
Default: falseYou should see the template in the list of templates from dotnet new list after this installs successfully. Look for "ASP.NET Clean Architecture Solution" with Short Name of "clean-arch".
Navigate to the parent directory in which you'd like the solution's folder to be created.
Run this command to create the solution structure in a subfolder name Your.ProjectName:
dotnet new clean-arch -o Your.ProjectName
The Your.ProjectName directory and solution file will be created, and inside that will be all of your new solution contents, properly namespaced and ready to run/test!
Example:
Thanks @dahlsailrunner for your help getting this working!
Known Issues:
- Don't include hyphens in the name. See #201.
- Don't use 'Ardalis' as your namespace (conflicts with dependencies).
As of version 9, this solution template only includes support for API Endpoints using the FastEndpoints library. If you want to use my ApiEndpoints library, Razor Pages, and/or Controllers you can use the last template that included them, version 7.1. Alternately, they're easily added to this template after installation.
To use Ardalis.ApiEndpoints instead of (or in addition to) FastEndpoints, just add the reference and use the base classes from the documentation.
dotnet add package Ardalis.ApiEndpointsYou'll need to add support for controllers to the Program.cs file. You need:
builder.Services.AddControllers(); // ControllersWithView if you need Views
// and
app.MapControllers();Once these are in place, you should be able to create a Controllers folder and (optionally) a Views folder and everything should work as expected. Personally I find Razor Pages to be much better than Controllers and Views so if you haven't fully investigated Razor Pages you might want to do so right about now before you choose Views.
You'll need to add support for Razor Pages to the Program.cs file. You need:
builder.Services.AddRazorPages();
// and
app.MapRazorPages();Then you just add a Pages folder in the root of the project and go from there.
To get started based on this repository, you need to get a copy locally. You have three options: fork, clone, or download. Most of the time, you probably just want to download.
You should download the repository, unblock the zip file, and extract it to a new folder if you just want to play with the project or you wish to use it as the starting point for an application.
You should fork this repository only if you plan on submitting a pull request. Or if you'd like to keep a copy of a snapshot of the repository in your own GitHub account.
You should clone this repository if you're one of the contributors and you have commit access to it. Otherwise you probably want one of the other options.
You shouldn't need to do this to use this template, but if you want migrations set up properly in the Infrastructure project, you need to specify that project name when you run the migrations command.
In Visual Studio, open the Package Manager Console, and run Add-Migration InitialMigrationName -StartupProject Your.ProjectName.Web -Context AppDbContext -Project Your.ProjectName.Infrastructure.
In a terminal with the CLI, the command is similar. Run this from the Web project directory:
dotnet ef migrations add MIGRATIONNAME -c AppDbContext -p ../Your.ProjectName.Infrastructure/Your.ProjectName.Infrastructure.csproj -s Your.ProjectName.Web.csproj -o Data/MigrationsTo use SqlServer, change options.UseSqlite(connectionString)); to options.UseSqlServer(connectionString)); in the Your.ProjectName.Infrastructure.StartupSetup file. Also remember to replace the SqliteConnection with DefaultConnection in the Your.ProjectName.Web.Program file, which points to your Database Server.
To update the database use this command from the Web project folder (replace Clean.Architecture with your project's name):
dotnet ef database update -c AppDbContext -p ../Clean.Architecture.Infrastructure/Clean.Architecture.Infrastructure.csproj -s Clean.Architecture.Web.csprojThe goal of this repository is to provide a basic solution structure that can be used to build Domain-Driven Design (DDD)-based or simply well-factored, SOLID applications using .NET Core. Learn more about these topics here:
If you're used to building applications as single-project or as a set of projects that follow the traditional UI -> Business Layer -> Data Access Layer "N-Tier" architecture, I recommend you check out these two courses (ideally before DDD Fundamentals):
Steve Smith also maintains Microsoft's reference application, eShopOnWeb, and its associated free eBook. Check them out here:
- eShopOnWeb on GitHub (now supported by NimblePros
- Architecting Modern Web Applications with ASP.NET Core and Microsoft Azure (eBook)
Note that the goal of this project and repository is not to provide a sample or reference application. It's meant to just be a template, but with enough pieces in place to show you where things belong as you set up your actual solution. Instead of useless "Class1.cs" there are a few real classes in place. Delete them as soon as you understand why they're there and where you should put your own, similar files. There is a sample application in the /sample folder, if you're looking for that.
I've used this starter kit to teach the basics of ASP.NET Core using Domain-Driven Design concepts and patterns for some time now (starting when ASP.NET Core was still in pre-release). Typically I teach a one- or two-day hands-on workshop ahead of events like DevIntersection, or private on-site workshops for companies looking to bring their teams up to speed with the latest development technologies and techniques. Feel free to contact me if you'd like information about upcoming workshops.
The goal of this solution template is to provide a fairly bare-bones starter kit for new projects. It does not include every possible framework, tool, or feature that a particular enterprise application might benefit from. Its choices of technology for things like data access are rooted in what is the most common, accessible technology for most business software developers using Microsoft's technology stack. It doesn't (currently) include extensive support for things like logging, monitoring, or analytics, though these can all be added easily. Below is a list of the technology dependencies it includes, and why they were chosen. Most of these can easily be swapped out for your technology of choice, since the nature of this architecture is to support modularity and encapsulation.
Validation of user input is a requirement of all software applications. The question is, where does it make sense to implement it in a concise and elegant manner? This solution template includes 4 separate projects, each of which might be responsible for performing validation as well as enforcing business invariants (which, given validation should already have occurred, are usually modeled as exceptions).
The domain model itself should generally rely on object-oriented design to ensure it is always in a consistent state. It leverages encapsulation and limits public state mutation access to achieve this, and it assumes that any arguments passed to it have already been validated, so null or other improper values yield exceptions, not validation results, in most cases.
The use cases / application project includes the set of all commands and queries the system supports. It's frequently responsible for validating its own command and query objects. This is most easily done using a chain of responsibility pattern via MediatR behaviors or some other pipeline.
The Web project includes all API endpoints, which include their own request and response types, following the REPR pattern. The FastEndpoints library includes built-in support for validation using FluentValidation on the request types. This is a natural place to perform input validation as well.
Having validation occur both within the API endpoints and then again at the use case level may be considered redundant. There are tradeoffs to adding essentially the same validation in two places, one for API requests and another for messages sent to Use Case handlers. Following defensive coding, it often makes sense to add validation in both places, as the overhead is minimal and the peace of mind of mind and greater application robustness is often worth it.
The Core project is the center of the Clean Architecture design, and all other project dependencies should point toward it. As such, it has very few external dependencies. The Core project should include the Domain Model including things like:
- Entities
- Aggregates
- Value Objects
- Domain Events
- Domain Event Handlers
- Domain Services
- Specifications
- Interfaces
- DTOs (sometimes)
You can learn more about these patterns and how to apply them here:
An optional project, I've included it because many folks were demanding it and it's easier to remove than to add later. This is also often referred to as the Application or Application Services layer. The Use Cases project is organized following CQRS into Commands and Queries (I considered having folders for Commands and Queries but felt it added little - the folders per actual command or query is sufficient without extra nesting). Commands mutate the domain model and thus should always use Repository abstractions for their data access (Repositories are how one fetches and persists domain model types). Queries are readonly, and thus do not need to use the repository pattern, but instead can use whatever query service or approach is most convenient.
Since the Use Cases project is set up to depend on Core and does not depend on Infrastructure, there will still need to be abstractions defined for its data access. And it can use things like specifications, which can sometimes help encapsulate query logic as well as result type mapping. But it doesn't have to use repository/specification - it can just issue a SQL query or call a stored procedure if that's the most efficient way to get the data.
Although this is an optional project to include (without it, your API endpoints would just work directly with the domain model or query services), it does provide a nice UI-ignorant place to add automated tests, and lends itself toward applying policies for cross-cutting concerns using a Chain of Responsibility pattern around the message handlers (for things like validation, caching, auth, logging, timing, etc.). The template includes an example of this for logging, which is located in the SharedKernel NuGet package.
Most of your application's dependencies on external resources should be implemented in classes defined in the Infrastructure project. These classes should implement interfaces defined in Core. If you have a very large project with many dependencies, it may make sense to have multiple Infrastructure projects (e.g. Infrastructure.Data), but for most projects one Infrastructure project with folders works fine. The template includes data access and domain event implementations, but you would also add things like email providers, file access, web api clients, etc. to this project so they're not adding coupling to your Core or UI projects.
The entry point of the application is the ASP.NET Core web project (or possibly the AspireHost project, which in turn loads the Web project). This is actually a console application, with a public static void Main method in Program.cs. It leverages FastEndpoints and the REPR pattern to organize its API endpoints.
A Shared Kernel is used to share common elements between bounded contexts. It's a DDD term but many organizations leverage "common" projects or packages for things that are useful to share between several applications.
I recommend creating a separate SharedKernel project and solution if you will require sharing code between multiple bounded contexts (see DDD Fundamentals). I further recommend this be published as a NuGet package (most likely privately within your organization) and referenced as a NuGet dependency by those projects that require it.
Previously a project for SharedKernel was included in this project. However, for the above reasons I've made it a separate package, Ardalis.SharedKernel, which you should replace with your own when you use this template.
If you want to see another example of a SharedKernel package, the one I use in my updated Pluralsight DDD course is on NuGet here.
Test projects could be organized based on the kind of test (unit, functional, integration, performance, etc.) or by the project they are testing (Core, Infrastructure, Web), or both. For this simple starter kit, the test projects are organized based on the kind of test, with unit, functional and integration test projects existing in this solution. Functional tests are a special kind of integration test that perform subcutaneous testing of the APIs of the Web project, without actually hosting a real website or going over the network. I've created a bunch of test helpers to make these kinds of tests shorter and easier to maintain.
This solution template has code built in to support a few common patterns, especially Domain-Driven Design patterns. Here is a brief overview of how a few of them work.
Domain events are a great pattern for decoupling a trigger for an operation from its implementation. This is especially useful from within domain entities since the handlers of the events can have dependencies while the entities themselves typically do not. In the sample, you can see this in action with the ToDoItem.MarkComplete() method. The following sequence diagram demonstrates how the event and its handler are used when an item is marked complete through a web API endpoint.
