Clean Architecture with .NET and .NET Core – Explained

Clean Architecture is a software design approach that separates concerns into distinct layers with clear boundaries. This makes the application easier to understand, maintain, and scale over time. In this post, we'll explore implementing clean architecture in .NET and .NET Core.

What is Clean Architecture?

Clean architecture was first proposed by Robert C. Martin (Uncle Bob) and focuses on the following principles:

• The interior layers don't know anything about the outer layers. They should only depend on layers more central.
• Inner layers define interfaces that allow outer layers to interact with them without knowing their implementation details.
• Domain logic sits at the core and doesn't depend on infrastructure concerns like databases, UI, etc.
• This separation of concerns makes the core domain logic easy to test and resistant to changes in external factors like UI frameworks and databases.

Clean Architecture Layers

Clean architecture organizes code into layers based on their level of abstraction. Here are the common layers from the most abstract to the most concrete:

• Domain Layer: Contains enterprise business rules and domain objects like entities, value types, repositories interfaces etc. Doesn't depend on any other layer.
• Application Layer: Implements use cases and application services. Orchestrates workflow between domains objects and outer layers. Depends only on domain layer.
• Infrastructure Layer: Provides implementations for outer services like database access, messaging, email etc. Depends only on application and domain layers.
• UI Layer: Contains UI and framework specific code like MVC controllers, API controllers, etc. Depends on all other layers.

This layered design produces a stable core model insulated from frequent changes at the periphery.

Implementing Clean Architecture in .NET

Let's see how we can implement clean architecture in an ASP.NET Core application. We'll create a simple TODO application with the following specs:

• Manage TODO items with operations like add, complete, delete etc.
• Persist TODOs in a database
• Expose TODOs via a REST API
• Create a web UI to manage TODOs

We'll structure the solution into projects corresponding to each layer:

• TodoApp.Domain: Class library project with entities, models, interfaces
• TodoApp.Application: Class library with application services
• TodoApp.Infrastructure: Class library implementing persistence and other outer services
• TodoApp.WebUI: ASP.NET Core project for Web UI
• TodoApp.Api: ASP.NET Core project exposing REST APIs

TodoApp.Domain

This project contains the core domain classes like the TodoItem entity along with repository interfaces:

The domain doesn't depend on any other project. We just define the business entities and abstract repositories here.

TodoApp.Application

This layer contains use cases and application services that use domain objects:

The application project depends only on the domain project and defines interfaces that are implemented by outer layers.

TodoApp.Infrastructure

This layer provides concrete implementations for repositories declared in the domain:

We keep infrastructure code like data access and messaging here isolated from the application's core logic.

TodoApp.WebUI

The WebUI project is built using ASP.NET Core MVC and depends on all other layers. It allows performing use cases through controllers and also implements web specific concerns like authentication:

The WebUI uses interfaces defined in Application layer and doesn't depend on infrastructure implementations.

TodoApp.Api

We can also build a REST API project which depends on the application layer. The controllers construct request models and pass them to the application services:

This separation of APIs from the backend business logic allows us to support multiple client types easily.

Benefits

Using this architecture provides the following advantages:

• Domain logic is isolated and can be easily tested without infrastructure
• Outer layers can be modified without changing core domain
• Business rules are cleanly encapsulated in the domain
• Adding new delivery mechanisms like mobile apps is easy
• Infrastructure layers can be swapped based on technology needs

So with some planning, we can leverage clean architecture with .NET and .NET Core and build maintainable applications that last.

Final Words

In this post, we looked at implementing a layered clean architecture in .NET Core. The key points are:

• Separate core domain from infrastructure concerns
• Domain doesn't depend on other layers
• Use interfaces to abstract dependencies
• Outer layers depend only on inner layers

With a clean separation of concerns, changes are isolated and core domain logic stays decoupled. This results in apps that are easier to maintain and extend over time. Clean architecture may require more upfront planning but pays off through increased agility long-term.