The Onion Architecture was implemented by Jeffrey Palermo and provides an efficient way to build applications to improve their testing, maintenance and dependency management. In Onion, layers communicate through interfaces so it is intended for object-oriented programming languages.

This type of architecture is based on the inversion of dependencies, the dependencies go from outside to inside. It is composed of several concentric layers that communicate through interfaces as we approach the center. It is here in the center where we have the domain entities.

Why Onion Architecture

• Separation of responsibilities and clear boundaries between layers.
• It facilitates the testing of our application and maintenance.
• Provides ease of changing technologies at the infrastructure layer without affecting the core of the application.
• It focuses on domain rules and their logic.

Domain layer

It is the central layer of the Onion Architecture. Here the business and the behavior of the objects are represented. The entities are modeled in such a way that they do not depend on an ORM. They also have no external dependencies, i.e. the domain can only depend on itself. They have no input/output operations and are purely logical. This means that if our application makes use of ORM the entities are going to be simple classes without ORM logic.

Repository layer

The repository layer, or domain services, defines the interfaces that define our database persistence layer or any type of persistence, such as saving information in files within the application's file system. The implementation of these interfaces will be done in the infrastructure layer, since this type of implementations that can make our application unstable in case we have to change the database engine, are taken to the outermost layer in order to leave the business logic unchanged.

Service layer

The application layer implements the use cases. Here are our application services that implement the business logic. It is in charge of the interaction with the domain and infrastructure layers.

Presentation layer

This layer is the most peripheral of the Onion Architecture and is the one that communicates the application with the outside world. Here we have the infrastructure adapters that communicate with services such as RabbitMQ or the database. We can also have our user interface, for example an API, which receives requests from web or mobile clients. Finally we can also consider integration tests as part of this layer, since we could test our application as a whole.

Onion vs Clean Architecture

As we can see, in both Onion Architecture and Clean the center are the domain entities. We can see that they are very similar architectures, in fact Clean is inspired by Onion. It is necessary to take into account that Onion is thought to implement with object oriented languages, reason why a difference that we can see is that the repository layer does not appear in the Clean architecture, but in the Onion it is reflected with the declaration of repository interfaces.

The two architectures provide an optimal separation of responsibilities and allow us to test our application in layers easily thanks to unit tests, testing of the whole application with integration tests and the facility to change the implementation at application/infrastructure level in case we have to migrate our database, use a different one in our test environment or have to connect our application with a web service or a mobile app.