Please enable JavaScript.
Coggle requires JavaScript to display documents.
Onion arcitecture - Coggle Diagram
Onion arcitecture
Onion vs Hexagonal
The point of using either of them is that you focus on the real problem you are trying to solve, without using any technology or framework. The application is technology agnostic, and it is easy to migrate from a framework to another. Both of them are called "clean" architectures because of that. You have your application core free of framework code, annotations, etc.
Both Ports & Adapters and Onion Architecture share the idea of isolating the application core from the infrastructure concerns by writing adapter code so that the infrastructure code does not leak into the application core. This makes it easier to replace both the tools and the delivery mechanisms used by the application, providing some protection against technology, tooling and vendor lockdown.
onion
the wording that "the onion architecture considers UI and data access to be part of the same layer" can be interpreted in a different way than was intended. The point is that in the onion architecture, the user interface and data access functionality are not in a hierarchical relationship, as is the case in the layered architecture.
In Onion, there are layers, with the dependencies always pointing inwards, i.e., a layer can use any of the layers inside it. The inner layer is Domain Model and the outer is infrastructure, but the number of layers between may vary.
hexagonal
In Hexagonal there are no layers. You have the application, the ports, and the adapters. The ports belong to the application, they are the API/SPI of the application. Adapters are outside the application, and each one depends on a port of the application.
The confusion some people have is that when implementing the hexagonal architecture, most of the people don't physically put every adapter in an artifact, but they put all together into one artifact (like the infrastructure layer). And also they make depend on the adapters on the whole app, not just the port they use. So it would be an Onion in fact.
Implementing hexagonal right should separate adapters from each other, and every adapter should depend just on the port it uses/implements (depending on whether the port is a driver or driven).
Onion, Hexagonal, and Ports and Adapters are in fact all different names for the same conceptual architecture
-
it makes explicit the implicit idea of Ports & Adapters Architecture about the direction of dependencies:
-
-
Onion Architecture also tells us that, in enterprise applications, we will have more than those two layers, and it adds some layers in the business logic which we might recognise from Domain Driven Design
Onion Architecture builds on the Ports & Adapters Architecture to add some internal organisation to the business logic of the application based on a few Domain Driven Design concepts.
Again, this is an evolution in further segregating responsibilities, providing for low coupling and high cohesion, which in turn provides for more testability and maintainability.
The onion architecture is a specific application obeying the rules of Clean Architecture clean-archs