# How To Approach Clean Architecture Folder Structure

> Clean Architecture is a popular approach to structuring your .NET application. It's a layered architecture and splits into four layers: Domain, Application, Infrastructure, and Presentation. Each of the layers is typically one project in your solution. How do we create this in our .NET solutions?

Published: 2022-09-24. Author: Milan Jovanović.

Canonical: https://milanjovanovic.tech/blog/clean-architecture-folder-structure

[**Clean Architecture**](https://milanjovanovic.tech/blog/clean-architecture-dotnet) is a popular approach to structuring your application.

It's a layered architecture that splits the project into four layers:

- [Domain](#domain-layer)
- [Application](#application-layer)
- [Infrastructure](#infrastructure-layer)
- [Presentation](#presentation-layer)

Each of the layers is typically one project in your solution.

Here's a visual representation of the **Clean Architecture**:

![Clean Architecture layers with Domain at the center, surrounded by Application, Presentation, and Infrastructure](https://milanjovanovic.tech/blogs/mnw_004/clean_architecture.png)

How do we create this in our .NET solutions?

## Domain Layer

The [**Domain layer**](https://milanjovanovic.tech/blog/domain-layer-clean-architecture) sits at the core of the **Clean Architecture**.
Here we define things like: entities, value objects, aggregates, domain events, exceptions, repository interfaces, etc.

Here is the folder structure I like to use:

```
📁 Domain
|__ 📁 DomainEvents
|__ 📁 Entities
|__ 📁 Exceptions
|__ 📁 Repositories
|__ 📁 Shared
|__ 📁 ValueObjects
```

You can introduce more things here if you think it's required.

One thing to note is that the **Domain layer** is not allowed to reference other projects in your solution.

## Application Layer

The [**Application layer**](https://milanjovanovic.tech/blog/application-layer-clean-architecture) sits right above the **Domain layer**.
It acts as an orchestrator for the **Domain layer**, containing the most important use cases in your application.

You can structure your use cases using services or using commands and queries.

I'm a big fan of the **CQRS** pattern, so I like to use the command and query approach.

Here is the folder structure I like to use:

```
📁 Application
|__ 📁 Abstractions
    |__ 📁 Data
    |__ 📁 Email
    |__ 📁 Messaging
|__ 📁 Behaviors
|__ 📁 Contracts
|__ 📁 Entity1
    |__ 📁 Commands
    |__ 📁 Events
    |__ 📁 Queries
|__ 📁 Entity2
    |__ 📁 Commands
    |__ 📁 Events
    |__ 📁 Queries
```

In the `Abstractions` folder, I define the interfaces required for the **Application layer**.
The implementations for these interfaces are in one of the upper layers.

For every entity in the **Domain layer**, I create one folder with the commands, queries, and events definitions.

## Infrastructure Layer

The **Infrastructure layer** contains implementations for external-facing services.

What would fall into this category?

- Databases - PostgreSQL, MongoDB
- Identity providers - Auth0, Keycloak
- Emails providers
- Storage services - AWS S3, Azure Blob Storage
- Message queues - Rabbit MQ

Here is the folder structure I like to use:

```
📁 Infrastructure
|__ 📁 BackgroundJobs
|__ 📁 Services
    |__ 📁 Email
    |__ 📁 Messaging
|__ 📁 Persistence
    |__ 📁 EntityConfigurations
    |__ 📁 Migrations
    |__ 📁 Repositories
    |__ #️⃣ ApplicationDbContext.cs
|__ 📁 ...
```

I place my `DbContext` implementation here if I'm using **EF Core**.

It's not uncommon to make the Persistence folder its project.
I frequently do this to have all database facing-code inside of one project.

## Presentation Layer

The **Presentation layer** is the entry point to our system.
Typically, you would implement this as a Web API project.

The most important part of the **Presentation layer** is the `Controllers`, which define the API endpoints in our system.

Here is the folder structure I like to use:

```
📁 Presentation
|__ 📁 Controllers
|__ 📁 Middlewares
|__ 📁 ViewModels
|__ 📁 ...
|__ #️⃣ Program.cs
```

Sometimes, I will move the **Presentation layer** away from the actual Web API project.
I do this to isolate the `Controllers` and enforce stricter constraints.
You don't have to do this if it is too complicated for you.

## Is This The Only Way?

You don't have to follow the folder structure I proposed to the T.
**Clean Architecture** is very flexible, and you can experiment with it and structure it the way you like.

Do you like more granularity? Create more specific projects.

Do you dislike a lot of projects? Separate concerns using folders.

I'm here to give you options to explore. But it's up to you to decide what's best.

---

## Frequently asked questions

### What are the four layers of Clean Architecture?

Clean Architecture splits an application into the Domain, Application, Infrastructure, and Presentation layers. Each layer is typically one project in your .NET solution, with the Domain layer sitting at the core.

### What goes in the Domain layer?

The Domain layer contains entities, value objects, aggregates, domain events, exceptions, and repository interfaces. It sits at the core of the architecture and is not allowed to reference any other project in the solution.

### What is the Application layer responsible for?

The Application layer orchestrates the Domain layer and contains the most important use cases in the application. You can structure use cases with services or, following CQRS, with commands and queries, defining interfaces in an Abstractions folder and implementing them in upper layers.

### What belongs in the Infrastructure layer?

Implementations for external-facing services: databases like PostgreSQL or MongoDB, identity providers such as Auth0 or Keycloak, email providers, storage services like AWS S3 or Azure Blob Storage, and message queues like RabbitMQ. The EF Core DbContext also lives here.

### Do you have to use one project per layer in Clean Architecture?

No. Clean Architecture is very flexible. If you want more granularity, create more specific projects, such as a separate Persistence project for all database-facing code. If you dislike having many projects, separate concerns with folders instead.