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.

Abbildung : Schichtenarchitektur versus Hexagonale-, Onion- und Clean Architecture

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.

Abbildung : Growing Object-Oriented Software

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.