Son Yazılar

what is clean architecture

What is Clean Architecture and why you should use it?

What is Clean Architecture? Why should we separate our application into layers? What advantages can we expect?

Clean Architecture is an approach that is independent from frameworks. It is a structure that adopts the SOLID principles.

Why should we separate our application into layers?

In the system we want to develop; when changes are made to threads in a section, we want no changes in other sections. In addition, as the project grows, it becomes more and more difficult to read the codes. This encourages us to use layered architecture. If we make the threads loose-coupling or independent from each other, we can easily write tests and observe whether there is any problem in our system in the changes made later.


  • The ORM used for the database is independent. Let’s say, we used Entity Framework in our system. When we want to integrate Dapper in the future, we will not need to fix the codes. We will continue by creating class and interface structures for Dapper.
  • An easier testable structure will have been created.
  • Since it is independent from the interface, we can integrate the system we have created into any interface.
  • As we mentioned at the beginning of our article, it is independent from frameworks (.Net, Spring etc.).

Clean Architecture has 2 basic principles:

  • Abstraction Principle
  • Dependency Rule
clean architecture

Abstraction Principle: The further you go to the center of the circle, the more abstract they become.

Dependency Rule: Each circle will only need their one inner circle. For example, the Application layer is only dependent on the Domain layer.


Domain Layer:

  • Entities: The part that objectively corresponds to the tables in the database. For example, a Product Class structure representing the Products table.
  • Value Object: Objects that have an identity of their own are called Entities, while those that do not have an identity of their own are called value objects.
  • Exceptions: The exception classes we create for the Domain.
  • Logic: Logical operations related to the Domain layer.

Application Layer:

In this layer, we generally carry out our logical operations. It is the layer where incoming requests are processed, validated, and database records are made. The only attachment of this layer is the Domain layer.

  • Interfaces: It can be the mail service or the notification interfaces.
  • Models: The part that the models used in the application layer can be found.
  • Logic Commands / Queries: The part that contains the Request and Response models of the requests to the service, the logical operations of these services and database records.
  • Validators: The part where the validations of incoming requests are located.
  • Exceptions: The part where the Exception classes written for the occurred errors are located.

Infrastructure Layer:

This layer contains the external units to be added to the system. There should be no layer dependency to this layer.

  • EF Core DbContext
  • Dapper
  • Redis Cache Service
  • Email
  • SMS

Presentation Layer:

This layer should not contain business codes. Business codes are made in the Application layer and communicated with the presentation layer.

  • Single Page Application (React, Angular, Vue …)
  • MVC
  • API