“It’s basic research: shoot an arrow in the air. Where it lands, paint a bullseye.”
Elizabeth Streb
I call Hexagonal Architecture, Onion Skin Model and Clean Architecture the “Bullseye Architectures”, because they contain the domain logic as a central component in the middle of their structure. These architectures organize the system structure around this central business logic, which is isolated from external influences such as databases and user interfaces by various layers. The aim is to increase flexibility, testability and maintainability by keeping the core application independent and modular.
The Hexagonal Architecture, also known as Ports and Adapters, structures the central domain layer (business logic) in such a way that it is surrounded by “ports” to which various “adapters” can be connected. This helps to minimize dependency on external systems and thus increase flexibility and testability.
The Onion Skin Model (Onion Architecture) consists of concentric rings. The innermost layer is the domain layer, followed by application, infrastructure and presentation components. This structure aims to promote the separation of domain logic and infrastructure while supporting reusability and modularity.
Clean Architecture introduces business objects (entities) at the center, which are surrounded by layers for use cases, interface adapters and infrastructures. The architecture aims to ensure maximum independence from external factors and a high degree of modularity, which improves the testability and maintainability of the software.
In comparison, the more traditional Multitier Architecture structures systems into horizontal layers, such as the presentation layer, business logic layer and data access layer. While these provide clear responsibilities and an easy-to-understand structure, they are often highly coupled with each other. This can lead to changes in one layer having a serious impact on other layers, which can affect flexibility and maintainability.
The Microservice Architecture breaks down the application into a collection of small, independent services, each with their own responsibilities and deployable independently. This improves scalability and enables independently deployable modules that are loosely coupled and easier to maintain and expand. However, this also increases the complexity of managing and orchestrating microservices, and often requires extensive infrastructure and DevOps knowledge.
Bullseye Architectures offer modern solutions for minimizing dependency on external systems and increasing testability and maintainability.
But are Bullseye Architectures architectures really better than the architectures used to date, such as the layered model? Reference is often made to legacy systems. However, this is a misconception based on a survivorship bias. What we see there are systems that have not received the care and attention they deserve over the years. Although they started out with a beautiful and well thought out architecture, over many years they have become ugly caricatures of their original elegance through carelessness and ignorance. Nevertheless, due to their field of application and functionality, they have managed to remain in service to this day.
Another curious trend is Modular Monoliths, which emphasize the clean separation of their components. This is not a special achievement, as software development has been pushing for clean separation at all levels since its inception. Anyone who builds a modular monolith today to replace a legacy monolith is only building the original monolith again.
The Bullseye Architectures have their merits and are a good choice for many subject areas. However, it should be clear to everyone that a new architecture will not save anyone who does not think sustainably and does not take measures to maintain these architectures in the long term.