Always will be ready notify the world about expectations as easy as possible: job change page
May 6

How to structure .NET project with Clean Architecture?


Clean Architecture in practice.

Clean Architecture

Clean Architecture is a popular approach to building software applications.

A Clean Architecture defines clear boundaries between different application layers, resulting in improved maintainability.

In addition, Clean Architecture approach aims to keep the business logic independent of any specific external frameworks or libraries, making it easier to migrate to new technologies.

In this article, we will look at how to structure a .NET project using Clean Architecture principles.

• • •

The Clean Architecture approach divides the solution into four main layers:

  • Domain (core logic)
  • Application (application use cases)
  • Infrastructure (data access, caching…)
  • Presentation (public API)

Clean Architecture

How do these layers depend on each other?

An important rule about dependencies between layers is that any inner circle must not know anything about the outer circles.

Therefore, dependencies between layers can only be directed inward.

Implementation of Clean Architecture

How to implement a clean architecture in a .NET project?

The easiest way is to create a separate project for each of the four layers shown in the diagram.

Clean Architecture diagram

However, a little later in the article, we will adjust this approach a bit.

Now let’s talk about each layer individually.

Domain Layer

The domain layer is where the domain logic of the application is defined.

This layer contains things like entities, value objects, domain services, domain exceptions, domain events, repository interfaces, and so on.

Important thing is that the domain layer does not depend on any other layer. It depends only on .NET primitive types (int, string, etc).

When it comes to grouping files into folders within a domain project, there are two common ways to do this.

The first option would be to group files by their type:

Domain Layer structure

All entities are placed in the Entities folder, all exceptions are placed in the Exception folder, and so on.

Another approach is to use entity folders.

For example, if the application contains domain logic related to users and orders, the file structure might look like this:


For a large domain layer, grouping by functionality by type (the first approach) may work better, because there will be no problem selecting a folder to put the file in. However, the second approach may have such difficulties, for example, when the same value object belongs to several different entities.

Application Layer

The application layer contains application’s use cases, which can be implemented as command and query handlers or simply as application service classes. In addition, the application layer is usually the place to define infrastructure abstractions (for caching, sending emails, etc).

Here’s what the folder structure might look like:

Application Layer

When it comes to references to other projects, the application layer only has a reference to the domain layer.

Infrastructure Layer

The infrastructure layer implements abstractions defined in application and domain layers.

The infrastructure layer can contain:

  • Repositories and database migrations
  • Implementation of caching services
  • Implementation of identity providers
  • Implementation of email providers

If the infrastructure layer is implemented as a single project, it may become too bloated over time.

To avoid this problem, we can implement the infrastructure layer as a folder with individual projects in it:

Infrastructure Layer

This approach provides a better separation of concerns.

The infrastructure layer must reference the domain and application projects to implement the abstractions defined in them.

Presentation Layer

The presentation layer serves as the entry point to the application.

It contains a public API (for example, RESTful endpoints) that external users or applications can interact with.

In addition to endpoints, the Presentation layer contains other elements needed to serve incoming requests, such as middlewares.

Presentation Layer

In addition, the presentation project acts as the composition root of the entire solution.

Composition root is where the dependency injection is configured.

Typically it’s done via a series of extension method calls in the Program class:


The presentation layer must reference the application layer in order to execute application use cases.

• • •

We looked at how to structure .NET applications using Clean Architecture principles. We saw how layers of Clean Architecture are mapped to .NET projects, how they should reference each other, and how to organize files within each project.

one month ago
Author: Sven Woltmann
In this article, you will learn: What is hexagonal architecture (or “ports & adapters” as this architecture is officially called)? What are the advantages of hexagonal architecture over classical layered architecture? What distinguishes hexagonal architecture from “clean architecture” and “onion...
Sep 14, 2023
Author: Rico Fritzsche
Balancing Business Needs: Evaluating Architecture in Domain-Driven Design One topic has come up again and again over the years, sometimes more, sometimes less, in conversations among developers: What’s the best way to modularize software? As a longtime software developer, I’ve...
Jun 28
Author: IT Illuminated
In the world of modern software development, the ability to perform multiple tasks simultaneously is important for building responsive and efficient applications. Have you ever wondered how your favorite apps handle multiple operations at once without slowing down? Or how...
Jun 7
Author: Stanley Ulili
Logging libraries vary in strengths, with some better suited for specific tasks than others. Certain projects demand lightweight solutions, while others require robust capabilities to handle high log data volumes. As a result, choosing a logging library can be challenging,...
Send message
Your name

© 1999–2024 WebDynamics
1980–... Sergey Drozdov
Area of interests: .NET Framework | .NET Core | C# | ASP.NET | Windows Forms | WPF | HTML5 | CSS3 | jQuery | AJAX | Angular | React | MS SQL Server | Transact-SQL | ADO.NET | Entity Framework | IIS | OOP | OOA | OOD | WCF | WPF | MSMQ | MVC | MVP | MVVM | Design Patterns | Enterprise Architecture | Scrum | Kanban