Die Grenzen der Schichtenarchitektur - Hexagonal-, Onion- & Clean-Architecture im Vergleich, Teil 1

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 ersten Teil geht es um die Grenzen der Mehrschichtenarchitektur, die die anderen Architekturstile zu überwinden versprechen.

1. Die Mehrschichtenarchitektur

Eine Anwendung kann in Schichten gegliedert werden. Jede dieser Schichten kümmert sich um einen anderen Aspekt der Anwendung.

Die Aufteilung basiert auf dem Prinzip „Separation of Concerns“, der Trennung von Verantwortlichkeiten. In der Praxis heißt das: Wir teilen die Anwendung in Schichten auf z.B. mit der beliebten Dreischichtenarchitektur:

Die Benutzeroberfläche, ist für alles zuständig, was der Nutzer sieht und womit er interagiert.
Die Geschäftslogik, also die Regeln und Prozesse, die bestimmen, wie Daten verarbeitet werden ist in der mittleren Schicht angesiedelt.
Die unterste Schicht, kümmert sich um die Verwaltung der Daten.

Jede dieser Schichten stellt der darüberliegenden Schicht Dienste zur Verfügung und verbirgt ihre eigenen inneren Details. Das bedeutet, dass z.B. Web-Entwickler sich nicht darum kümmern müssen, wie die Datenbank funktioniert. Sie arbeiten mit den Schnittstellen, die ihnen von den darunterliegenden Schichten zur Verfügung gestellt werden.

Wichtig ist, dass die Abhängigkeiten immer von oben nach unten verlaufen. Eine Schicht kennt und nutzt also nur die Schichten unter ihr, niemals die darüber. Das sorgt dafür, dass der Code leichter verständlich und besser wartbar ist.

Abbildung : Abhängigkeiten in der Schichtenarchitektur

Ein großer Vorteil dieser Architektur ist, dass Schichten einfach ausgetauscht werden können. Zum Beispiel kann die Benutzeroberfläche durch eine neue ersetzt werden, die vielleicht mit einer anderen Technologie arbeitet, ohne dass die darunterliegenden Schichten angepasst werden müssen.

1.1 Grenzen der Schichtenarchitektur

Die Schicht mit der Geschäftslogik, ist von der darunterliegenden Datenschicht abhängig, d.h. der Code in der Domain kennt und verwendet Strukturen und Verhalten aus der Datenschicht.

Abbildung : Notwendige Änderungen beim Austausch der Datenbank

Wenn die Datenbank ausgetauscht wird, dann muss nicht nur die Datenschicht angepasst werden, es sind auch Änderungen in der Schicht mit der Geschäftslogik notwendig.

Wir möchten verhindern, dass eine Änderung in der Datenschicht, uns zu Änderungen in der Geschäftslogik zwingt. Besonders wenn wir Domain-Driven Design anwenden, sollte der Bounded Context mit der Geschäftslogik nicht durch Infrastruktur-Code verschmutzt werden.

Die Schichtenarchitektur hat Vorteile und sie hat sich in den letzten Jahrzehnten in vielen großen Projekten bewährt. Es bleibt jedoch die Einschränkung, dass fachlicher Code von der Infrastruktur abhängig ist. Und zur Infrastruktur gehört nicht nur die Datenbank, sondern auch andere Dienste wie Mail, APIs, Message Broker und so weiter.

Abbildung : Infrastruktur neben der Datenbank

Im nächsten Artikel geht es um die Grundlage der Hexagonalen Architektur, dem Dependency Inversion Prinzip.