Clean Architecture

Clean architecture is a domain-centric architectural pattern that separates the business logic into two layers (application layer and domain layer) and uses interfaces to achieve separation of concerns and maintainability.

Key insights

• Clean architecture is a domain-centric architectural pattern that focuses on well-defined interactions between logical components.
• Clean Architecture involves making decisions based on business logic, such as determining whether a user can set a reminder or if they have reached their maximum limit.
• The dependency between the business logic and the data access layer can lead to complications, especially when the presentation layer also relies on the business logic.
• In clean architecture, the business logic is not just in one layer, but in two different layers - the application layer and the domain layer.
• How can the core logic of the application access the database without a dependency?
• The placement of the infrastructure layer above the core logic of the application may seem counter intuitive, but it is achieved by defining interfaces in the inner layers and implementing them in the outer layers, ensuring separation of concerns and maintainability.
• The application layer in clean architecture defines the use cases and interfaces, while the infrastructure layer handles the actual implementation and accessing the database or other infrastructure concerns

The diagram consists of concentric circles representing the different layers of the system.

As you get closer to the center, you will find high-level abstract details like the Domain Entities.

Moving outwards, you will encounter low-level implementation details like services, databases, etc.

Let’s have a look at what is inside each of these layers.

Domain Layer

At the heart of the system is the Domain Layer. The domain layer consists of the core business entities.

All the other layers in the system depend on the Domain layer and are there to support the Domain Layer.

Domain Layer itself does not depend on any other Layer.

Application Layer

Neighboring the Domain Layer is the Application Layer.

The Application layer is where all the magic happens. This is where your business logic resides.

Based on the business rules and regulations, this layer controls the flow of data to and from your business entities.

Generally, this layer consists of all your services, commands, queries, exceptions, logs, etc.

Infrastructure Layer

Next, we have the Infrastructure Layer. This is where all your external services and database logic are located.

All your external services, like email service, storage solutions, message queues, third-party API calls, etc., are handled by this layer.

Besides, it is also a common practice to separate database logic into its own Persistence Layer. This is where your DbContext and migrations, etc., will go.

Presentation Layer

Lastly, we have the presentation layer. This is the gateway or the entry point to your application.

This layer is responsible for presenting data to the end user in an easily understandable manner.

You will probably implement this layer as a Web or API project consisting of controllers defining the Action Methods or API endpoints.

What is the dependency rule?

Uncle Bob explains the dependency rule by making use of the diagram with the concentric circles. Software applications are divided in different areas or layers, each represented by a circle. Therefore you would think that the dependency rule cannot exist without the layers or the circles.

Using the circles, the dependency rule is a rule that states that dependencies should only point inwards, towards the centre of the circles. So the outer circle depends on the next inner circle, and so on. To use Uncle Bob’s words: “Nothing in an inner circle can know anything at all about something in an outer circle”. If it comes down to explaining how to use this dependency rule, it doesn’t get any clearer than this.