Unterschiede und Gemeinsamkeiten von Architekturen

Wie bereits erwähnt, fehlt bei der Hexagonalen Architektur eine explizite Definition des Anwendungskerns. Dies stellt einen wesentlichen Unterschied zu den Onion- und Clean- Architekturen dar, bei denen die Struktur und Definition des Anwendungskerns klar definiert sind. Außerdem unterscheiden sich die Terminologie der Architekturen stark, jedoch teilen alle drei Architekturen dieselben grundlegenden Prinzipien. Dazu gehören:

• Zentralisierte Geschäftslogik: 
  Die Idee, die Geschäftslogik in den Mittelpunkt zu stellen, wird sowohl von der Clean Architektur als auch von der Hexagonalen und Onion Architektur unterstützt. Obwohl diese Architekturansätze unterschiedliche Begriffe für ähnliche Konzepte verwenden, legen sie alle nahe, dass die Geschäftslogik auf ähnliche Weise betrachtet werden sollten. Darüber hinaus setzen diese Architekturen das Konzept des DDD um, indem sie die Geschäftslogik isolieren und die Abhängigkeiten von der Infrastruktur auflösen.
• Dependency Rule (Regel der Abhängigkeit): 
  In allen drei Architekturen werden unterschiedliche Bereiche der Software mittels konzentrischer Schichten veranschaulicht. Die grundlegende Regel, die die Architektur zum Funktionieren bringt, ist die Regel der Abhängigkeit. Diese Regel gilt einheitlich für alle drei Architekturen. Sie besagt, dass sich alle Abhängigkeiten im Quellcode nur nach innen zeigen sollen. Die äußeren Schichten dürfen auf die inneren Schichten verweisen, jedoch dürfen die inneren Schichten keine Kenntnis über Objekte in den äußeren Schichten haben. Insbesondere ist es untersagt, dass der Code in den inneren Schichten auf Funktionen, Klassen, Variablen oder andere benannte Software-Entitäten in den äußeren Schichten verweist.
  Außerdem sind die Schichten in der Darstellung von Architekturen schematisch. Das bedeutet, dass es keine feste Regel gibt, die besagt, dass immer nur diese vier Schichten bei der Clean Architektur bzw. Onion Architektur vorhanden sein müssen. Je nach Anforderungen kann es mehr oder weniger als nur diese vier Schichten geben. Unabhängig davon bleibt jedoch die Abhängigkeitsregel bestehen, dass die Quellcode-Abhängigkeiten immer nach innen zeigen.
• Geschäftslogik ist unabhängig von Infrastruktur, Datenbank, UI und Frameworks: 
  Die drei Architekturen betonen eindeutig, dass verschiedene Teile der Anwendung unabhängig voneinander entwickelt werden sollten und dass eine angemessene Abstraktion zwischen den einzelnen Schichten vorhanden sein sollte.
• Mapping: 
  Um die Entkopplung der technischen Details vom Anwendungskern zu gewährleisten, werden bei allen drei Architekturen Mapper verwendet. Ein Mapper fungiert als Isolator zwischen Schichten. Seine Aufgabe besteht darin, Daten zwischen verschiedenen Schichten des Systems zu verschieben. Dabei sorgt er dafür, dass die Details dieser Datenübertragung abstrahiert werden.

Nach der Analyse zeigt sich, dass die Architekturen zwar deutliche Ähnlichkeiten aufweisen und auf dem gleichen Konzept basieren, sich jedoch Unterschiede in folgenden Aspekten feststellen lassen:

• Die Konkretheit der Architekturdefinition: 
  Die Hexagonale Architektur ist eine spezifischere Ausprägung der Clean Architecture. Während die Clean Architektur viele abstrakte Konzepte enthält, geht die Hexagonale Architektur einen Schritt weiter und bietet eine konkretere Struktur in Form von Ports und Adaptern. Dadurch wird die Umsetzung der Hexagonalen Architektur als einfacher empfunden. Sowohl die Hexagonale Architektur als auch die Onion Architektur können als Subtypen der Clean Architektur betrachtet werden. Diese Einschätzung beruht nicht darauf, dass die Clean Architektur zuerst entwickelt wurde, sondern vielmehr darauf, dass sie rein logisch betrachtet die abstrakteste der drei Architekturen ist.
• Die Abhängikeitsregel: 
  Ein wesentlicher Unterschied besteht in der Onion Architektur. Im Gegensatz zu anderen Architekturansätzen erlaubt sie nicht nur den Zugriff auf die unmittelbar drunterliegende Schicht, sondern ermöglicht auch das Überspringen einer Schicht. Dies wird deutlich anhand der Tatsache, dass die Application-Service-Schicht nicht nur auf die Domain-Service-Schicht, sondern auch direkt auf die Domain-Model-Schicht zugreifen kann.
• Der Stil der Präsentation: 
  Der Unterschied im sprachlichen Stil, mit dem verschiedene Autoren diese Architekturen beschreiben, ist deutlich erkennbar und könnte als am validesten angesehen werden. Obwohl alle Architekturen dasselbe Ziel verfolgen und dieselbe Grundidee und Struktur zur Trennung von Verantwortlichkeiten haben, gibt es Unterschiede in der Art und Weise, wie sie von verschiedenen Autoren präsentiert werden. Es handelt sich um unterschiedliche Architekturen, aber sie alle haben konzentrische Schichten mit verschiedenen Bezeichnungen. Letztendlich sind sie jedoch nur Namen. Es ist dieselbe Idee, aber mit unterschiedlicher Syntax.

Jetzt, da wir uns ausführlich mit der Theorie beschäftigt haben, werfen wir einen Blick darauf, wie das Ganze in der Praxis aussieht – konkret in der Paketstruktur. Dabei lassen sich interessante Parallelen sowie spezifische Nuancen zwischen den verschiedenen Architekturen erkennen.

Die Bestandteile einer Architektur profitieren von einer gut strukturierten Gliederung. Eine geeignete Form dieser Gliederung kann eine passende Paketstruktur sein. Insbesondere bei der Entwicklung von Greenfield-Softwareprojekten ist es wichtig, von Anfang an eine solide Paketstruktur zu etablieren.

Es gibt verschiedene Möglichkeiten zur Organisation des Codes, wie beispielsweise die Organisation nach Layers oder die Organisation nach Features, usw. In der folgenden Abbildung kann man aussagekräftige Paketstrukturen erkennen, die von links nach rechts den Architekturen Hexagonal, Onion und Clean direkt zugeordnet sind.

Die drei Architekturen - Hexagonale Architektur, Onion Architektur und Clean Architektur - verwenden teilweise unterschiedliche Begriffe für dasselbe Konzept. In der folgenden Tabelle wird eine Gegenüberstellung von entsprechenden konzeptionellen Überschneidungen der einzelnen Elemente jeder Architektur präsentiert.

Vor- und Nachteile

Abgesehen von den Unterschieden haben die domänenzetrischen Architektur auch die Vor- und Nachteile. Dies ist wichtig, da wir die Architekturen nicht als allmächtig betrachten sollten. Jede Architektur hat ihre eigenen Stärken und Schwächen, und es ist entscheidend, diese zu verstehen. Indem wir uns mit den Vor- und Nachteilen auseinandersetzen, können wir ein ausgewogenes Verständnis entwickeln und die geeignetste Architektur für ein bestimmtes Projekt wählen.

Einer der wesentlichen Vorteile dieser Architekturen besteht darin, dass sie klare Richtlinien und Strukturen für die Platzierung bestimmter Komponenten bereitstellen. Durch die definierten Regeln und Vorgaben wird eine klare Orientierung für Entwickler:innen geschaffen, insbesondere für diejenigen, die bisher keine Erfahrung mit solchen Architekturen hatten.

Ein weiterer Vorteil ist die Testbarkeit, da diese Architekturmuster architektonisch getestet werden können, beispielsweise mithilfe von ArchUnit.

Es ist jedoch ein Nachteil, dass diese Architekturen nicht so klar strukturiert sind, wie man es erwarten könnte. Sie bieten sowohl Struktur als auch Freiraum, was zu Unsicherheiten führen kann. Ein Beispiel hierfür ist die Hexagonale Architektur, bei der nicht genau festgelegt ist, wie die eingehenden Ports gestaltet werden sollen, ebenso wenig wie die Interfaces für Use Cases in der Clean Architecture. Dies wirft die Frage auf, wenn man eine solche Architektur vorschlägt, warum dann nicht richtig?!

Viele von euch würden sicherlich zustimmen, dass das Mapping in diesen Architekturen als Nachteil betrachtet werden kann. Es verursacht einen erheblichen Aufwand und führt zu einer Vielzahl von Datenkopien, was die Komplexität erhöht und potenziell die Performance beeinträchtigen kann.

Einsatz und Verzicht auf Architekturen: Entscheidungskriterien

Es ist von großer Bedeutung zu überlegen, welche der drei Architekturen man in einem bestimmten Kontext umsetzen sollte. Mein Rat ist: Verwendet die Architektur, mit der ihr euch wohlfühlen! Die wichtige Frage ist, wann verwende ich überhaupt eine domänenzetrische Architektur?

Diese domänenzetrischen Architekturen sollten nur dann verwendet werden, wenn sie ihre Stärken ausspielen können. Wenn die Menge an Fachlogik sehr gering ist, bringen keine dieser Architekturen einen Mehrwert. Zusätzlich sollte die Möglichkeit bestehen, bei Bedarf die Teile des Systems zu extrahieren und eigenständig betreiben zu können.

Bei der Auswahl der Architektur für ein bestimmtes Projekt müssen verschiedene Faktoren berücksichtigt werden, wie die Art der Daten, die Art des Problems und die verfügbaren Ressourcen. Eine sorgfältige Analyse der Anforderungen und Einschränkungen ist erforderlich, um eine fundierte Entscheidung darüber zu treffen, welche Architektur am besten geeignet ist. Es ist auch möglich, dass in manchen Fällen alternative Ansätze oder einfachere Modelle effektiver sein können. Daher kann es in bestimmten Szenarien, wie zum Beispiel CRUD-Anwendungen oder BI-Anwendungen, sinnvoller sein, eine einfache Schichtenarchitektur zu wählen, wenn die Anwendung keine umfangreiche Geschäftslogik erfordert. In solchen Fällen könnten die genannten drei Architekturen eher hinderlich sein.

Fazit

Wenn ihr mich fragt, sollten die betrachteten Architekturen trotz ihrer Ähnlichkeiten auf keinen Fall als dasselbe betrachtet werden. Jede dieser Architekturen wurde von verschiedenen Personen entwickelt, die ihre individuellen Ideen, Erfahrungen und Einsichten in die Gestaltung der Architektur eingebracht haben. Letztendlich ist die Wahl zwischen diesen Architekturen tatsächlich häufig eine Frage des persönlichen Geschmacks und der individuellen Präferenzen der Entwickler:innen und Architekt:innen. Es ist daher wichtig zu verstehen, dass diese Architekturmuster nicht im direkten Wettbewerb zueinander stehen.