Anstatt zu lesen kannst du auch das Video zum Artikel auf YouTube anschauen.
Hexagonal-, Onion- & Clean-Architecture, Vergleich und Fazit, Teil 6
Von: Thomas Bayer
Datum: 8. Juli 2024
Aktualisiert: 15. Juli 2024
Diese Einleitung führt leicht verständlich in die Softwarearchitekturen Hexagonal-, Onion- und Clean-Architecture ein.
In diesem letzten Teil werden die Architekturen verglichen und es wird erörtert, ob sich die Verwendung der Architekturen lohnt. Für Entwickler, die das Spring Framework oder Spring Boot verwenden, wird auf die Unterschiede eingegangen.
6. Vergleich und Fazit
Bei der Schichtenarchitektur ist jede Schicht von der darunterliegenden Schicht abhängig. Bei der hexagonalen, Onion- und Clean-Architecture wird durch Dependency Inversion die Richtung der Abhängigkeit umgedreht, sodass diese immer zur Fachlichkeit zeigt.
![](/hex-onion-clean/vergleich.png)
Abbildung :
Hexagonale, Onion- und Clean-Architecture unterscheiden sich nur unwesentlich in der Darstellung, den Bezeichnungen oder der Anzahl der Schichten.
Eigentlich sind alle drei Architekturen gleich. Sie haben das gleiche Ziel, die Fachlichkeit von der Technik zu entkoppeln und nutzen dafür das Dependency-Inversion-Prinzip.
Warum gibt es drei Architekturen, wenn es kaum Unterschiede gibt? Die Konzepte wurden zwischen 2005 und 2012 in Blogposts oder in Artikeln beschrieben. Aufmerksamkeit und Verbreitung haben alle drei erst viel erfahren. Die Entwicklung verlief einfach unabhängig voneinander parallel. Zum Beispiel hatte Cockburn die hexagonale Architektur aus den Augen verloren, bis er seine Architektur Jahre später im Buch Growing Object-Oriented Software beschrieben fand.
![](/hex-onion-clean/vergleich-growing-oo.png)
Abbildung :
Für welche der drei Architekturen ihr euch entscheidet, ist im Prinzip egal. Ihr könnt also nach persönlichem Geschmack entscheiden.
10. Java und Spring
Wer das Spring Framework oder sogar Spring Boot richtig einsetzt, der hat bereits eine gute Trennung von Fachlichkeit und Infrastruktur. Nicht so radikal, wie bei den drei vorgestellten Architekturen, aber vielleicht ausreichend.
Wem das nicht genügt, der kann mit den Dependency Inversion Architekturen jede Abhängigkeit selbst die Spring Annotationen aus seinem Applikationskern verbannen.
9. Fazit
Die vorgestellten Architekturen ermöglichen die Trennung der Fachlichkeit von der Technik und unterstützen so das Domain Driven Design. Es ist gut, die Fachlichkeit zu isolieren, besonders bei großen Projekten. Allerdings erfordert das Abstraktionen in Form von Schnittstellen. Wenn diese oft angepasst werden müssen, sind Änderungen über Projekt- oder Dateigrenzen hinweg notwendig. Für viele Projekte ist dieser Aufwand zu hoch.
Je größer die Projekte, desto besser passen die auf Dependency-Inversion basierenden Architekturen. Wenn ihr nach Domain Driven Design vorgehen möchtet, solltet ihr euch auf jeden Fall die vorgestellten Architekturen genauer ansehen.