TP 148 Icon

About hexagons and onions


A classic layered architecture usually has three layers depending on each other. These are considered top-down and each layer only knows the layer directly below it. However, the dependency of the business layer and the persistence layer must be viewed critically:

Why is the business logic dependent on something like a database? Shouldn't it be possible to execute it independently of a framework or database?


One possible solution is hexagonal architecture or ports and adapters architecture. The central terms port and adapter are explained in the figure below.

In our example, the architecture consists of four layers: presentation, infrastructure, application, and domain, with the presentation layer omitted for a pure back-end system. However, these are not considered top-down, but from the outside in, with the domain being the core. Outer layers may access code from inner layers, but not vice versa. This principle corresponds to the basic idea of the onion architecture, which can be extended with interfaces and their implementations (ports and adapters) to enable access to other layers. The presentation layer (UI) is usually a separate project and will not be explained further in this paper. An overview of the other three layers follows:

Infrastructure Layer

  • Can contain framework-specific code
  • Contains configurations such as Spring or database configuration
  • Connects the output ports of the domain layer via adapters e.g. for the database or messaging

Application Layer

  • Provides interfaces or other applications for the user, e.g. REST, GraphQL, CLI etc.
  • Connects to the domain layer via adapter of an input port

Domain Layer

  • Contains the business logic
  • Is independent of a framework such as Spring
  • Allows communication between layers only via defined input and output ports
  • Code in this layer is unlikely to change
Onion Architecture

This structure makes individual classes easier to test and also to maintain and the business logic is independent and can be moved as a whole if necessary.

If you decide to use hexagonal architecture or a hybrid form with the onion architecture (as in the figure above), you must be aware of the higher complexity during implementation, which is why this architecture style is only worthwhile from a certain project size.

TP 148 Visual

Further Aspects


Author: Marcel Jacob / Software Engineer / Office Leipzig

Cookie Settings

This website uses cookies to personalize content and ads, provide social media features, and analyze website traffic. In addition, information about your use of the website is shared with social media, advertising, and analytics partners. These partners may merge the information with other data that you have provided to them or that they have collected from you using the services.

For more information, please refer to our privacy policy. There you can also change your cookie settings later on.

contact icon

Contact us now