Clean Architecture in .Net

Clean Architecture is a software design pattern that emphasizes separation of concerns, maintainability, and testability in .NET applications. It was introduced by Robert C. Martin, also known as Uncle Bob, in his book “Clean Architecture: A Craftsman’s Guide to Software Structure and Design”.

Clean Architecture involves breaking down a .NET application into multiple layers, each with its own set of responsibilities and dependencies. These layers include:

  • Presentation layer: Exposes the Web API endpoints and handles HTTP requests and responses. Depends on the Application layer interfaces.
  • Application layer: Implements the use cases of the application, orchestrating the Domain layer and Infrastructure layer to perform the necessary actions. Depends on the Domain layer and Infrastructure layer interfaces.
  • Domain layer: Defines the business entities and logic of the application, independent of the infrastructure or presentation details. Implements the Domain layer interfaces.
  • Infrastructure layer: Implements the interfaces defined in the Application layer and Domain layer, providing the necessary services and resources to accomplish the tasks. Depends on external services and libraries.
  • Tests: Contains unit and integration tests for the application.

The key principle of Clean Architecture is the Dependency Inversion Principle (DIP), which states that high-level modules should not depend on low-level modules; both should depend on abstractions. This allows for flexibility in the design and promotes modularity and testability.

Implementing Clean Architecture in .NET involves using design patterns such as Dependency Injection (DI), Inversion of Control (IoC), and Separation of Concerns (SoC) to achieve loose coupling and high cohesion between the layers. This helps to make the application more modular and easier to maintain, test, and evolve over time.

├── MyApp.Api/                      # Presentation layer (Web API)
│   ├── Controllers/               # HTTP controllers
│   ├── Filters/                   # Action filters
│   ├── Program.cs                 # Web API entry point
│   └── Startup.cs                 # Web API configuration
├── MyApp.Application/              # Application layer (Use cases)
│   ├── Commands/                  # Command handlers
│   ├── Queries/                   # Query handlers
│   ├── Interfaces/                # Application interfaces (ports)
│   └── MyApp.Application.csproj   # Application layer project file
├── MyApp.Domain/                   # Domain layer (Business entities and logic)
│   ├── Entities/                  # Domain entities
│   ├── Exceptions/                # Domain exceptions
│   ├── Interfaces/                # Domain interfaces (ports)
│   ├── Services/                  # Domain services
│   └── MyApp.Domain.csproj        # Domain layer project file
├── MyApp.Infrastructure/           # Infrastructure layer (Database, I/O, external services)
│   ├── Data/                      # Data access implementation (EF Core, Dapper, etc.)
│   ├── External/                  # External services implementation (REST APIs, gRPC, etc.)
│   ├── Migrations/                # Database migrations (EF Core)
│   ├── Interfaces/                # Infrastructure interfaces (ports)
│   ├── Logging/                   # Logging implementation
│   ├── MyApp.Infrastructure.csproj# Infrastructure layer project file
│   └── SeedData/                  # Seed data for database
├── MyApp.Tests/                    # Unit and integration tests
│   ├── MyApp.UnitTests/            # Unit tests
│   └── MyApp.IntegrationTests/     # Integration tests
└── MyApp.sln                       # Solution file

This is just one example of a possible clean architecture project structure. You can adapt it to your specific needs and preferences.