‚Clean Architecture‘ ist ein Architekturstil beim Aufbau einer IT-Anwendung. Im Zentrum von ‚Clean Architecture‘ und ähnlichen Stilen wie beispielweise der hexagonalen Architektur steht die Eigenschaft, die fachliche Anwendung unabhängig von der sonstigen Infrastruktur testen und weiterentwickeln zu können. Deshalb bilden bei der ‚Clean Architecture‘ die Geschäftsregeln den eigentlichen Kern der Anwendung und definieren somit ihren Wert. Vor allem bei komplexen Software-Projekten ist die Weiterentwicklung nie abgeschlossen. Mittels ‚Clean Architecture‘ wird deshalb verhindert, dass einzelne Software-Lösungen den Gesamtprozess beeinflussen und dadurch die unternehmerischen Abläufe belasten und behindern können. Ebenso können Komponenten der Infrastruktur spät festgelegt oder auch ausgetauscht beziehungsweise ersetzt werden, was einen weiteren Vorteil der ‚Clean Architecture‘ darstellt im Vergleich zu traditionellen Drei-Schichten-Architekturen.

‚Clean Architecture‘ vs. Drei-Schichten-Architektur

In vielen Systemen kommt immer noch eine Drei-Schichten-Architektur zum Einsatz. Die logischen Schichten dieses Stils lauten wie folgt:

• Präsentationsschicht (verantwortet gegenüber dem Anwender die Darstellung)
• Business-Logik-Schicht (enthält die Geschäftsregeln)
• Datenzugriffsschicht (prozessiert die Kommunikation mit der Datenbank)

Bei diesem Aufbau ist es grundlegend, dass die Komponenten einer Schicht ausschließlich von denen einer direkt darunter liegenden Schicht abhängig sein dürfen. Dadurch ist es möglich, eine höhere Schicht auszutauschen, ohne dass eine der darunter liegenden Schichten in irgendeiner Weise davon berührt wird. Vom Ablauf her interpretiert die Präsentationsschicht (User Interface Layer) die Eingaben des Anwenders und ruft die entsprechende Funktionalität in der Business-Logik-Schicht (Domain Layer) auf, die wiederum die Datenzugriffschicht (Data Access Layer) aufruft, um Daten aus einer Datenbank auszuwerten oder zu verändern.

Bei einer solchen Architektur hängt das gesamte System von der Datenzugriffsschicht ab und dadurch von der Datenbank selbst. Dies hat zur Folge, dass Änderungen bei der Anwendung, sobald sie persistente Daten betreffen, zuerst in der Datenbank beginnen und dann von unten nach oben durch die Schichten vorgenommen werden müssen. Diese Konstellation macht das Testen der eigentlichen Anwendung aufwändig und langsam und erschwert eine Weiterentwicklung enorm. Aus diesem Grund kommt eine solche Drei-Schichten-Architektur in ihrer Reinform kaum noch vor. Vielmehr werden solche Systeme teilweise durch Refactoring so umgebaut, dass die Business-Logik keine direkte Abhängigkeit von der Datenbank mehr hat.

Aufbau einer ‚Clean Architecture‘

Bei einer ‚Clean Architecture‘ wird die Business-Logik nicht durch einen Kunstgriff von der Datenbank entkoppelt, stattdessen bietet sie eine High-Level-Schnittstelle an, die von einem Persistenz-Mechanismus umgesetzt wird. Dadurch verschiebt sich auf der Architekturebene die Abhängigkeit von der Datenzugriffsschicht auf die Business-Logik-Schicht. Dies führt dazu, dass die Business-Logik von technischen Details unabhängig wird. Das erlaubt es dann sogar, die Business-Logik zu implementieren und zu testen, bevor man überhaupt eine Datenbank hat.

Somit wird es auch möglich, erst dann zu entscheiden, welche Datenbank-Technologie für die Anforderungen der Anwendung am geeignetsten ist, nachdem erst ausgiebig getestet wurde. Im Zuge dessen sind sowohl Datenzugriffs- als auch GUI-Komponenten abhängig von der Business-Logik, während diese von beidem völlig unabhängig bleibt. So kann erst nach ausgiebigem Testen entschieden werden, welche Datenbank-Technologie für die Anforderungen der Anwendung am geeignetsten ist. Im Zuge dessen sind sowohl Datenzugriffs- als auch GUI-Komponenten abhängig von der Business-Logik, während diese von beidem völlig unabhängig bleibt. Aus diesem Grund sollte die Business-Logik ebenso unabhängig von der GUI entwickelt werden, wie sie auch unabhängig von der Datenbank entwickelt wird.

Über den Kern der Geschäftsregeln legen sich weitere Schichten, die die Business-Logik weiter nach außen transportieren. Die inneren Kreise sind dabei Richtlinien, die äußeren sind Mechanismen. Das Besondere daran ist, dass Abhängigkeiten im Quellcode nur von einem äußeren Kreis in den nächsten inneren Kreis verweisen dürfen, was Robert C. Martin in seinem Beitrag auch die Dependency Rule nennt. So können die äußeren Schichten leicht angepasst und ausgetauscht werden, während der Kernprozess intakt bleibt. Vereinfacht ausgedrückt: Je weiter innen, desto näher am fachlichen Kern und je weiter außen, desto näher an technischen Details.

Der Aufbau einer ‚Clean Architecture‘ wird in folgender Grafik veranschaulicht:

Eigenschaften von Systemen mit einer ‚Clean Architecture‘

Mit den Geschäftsregeln, also der Business-Logik im Kern der Architektur werden schließlich Systeme erzeugt, die folgende Bedingungen erfüllen:

• Unabhängigkeit von Frameworks. Die Architektur hängt nicht von einer feature-überladenen Software-Bibliothek ab. Das ermöglicht es, Frameworks als Werkzeuge zu verwenden, anstatt die Geschäftsregeln in ein existierendes System-Korsett zu pressen
• Testfähigkeit. Die Geschäftsregeln können durch die Entkopplung vom System jederzeit ohne Nutzerinterface, Datenbank, Server oder andere externe Elemente getestet werden
• Unabhängigkeit von Nutzerinterfaces. Die Geschäftsregeln haben Bestand, auch wenn sich das Interface ändert: Sie können über eine Kommandozeile genauso abgebildet werden wie über eine grafische Nutzeroberfläche
• Unabhängigkeit von Datenbanken. Die Art der Speicherung und Verwaltung der Regeln ist nicht auf eine bestimmte Architektur angewiesen
• Unabhängigkeit von äußeren Einflüssen. Die Geschäftsregeln verfügen über keine Verbindung zur Außenwelt.

Einsatz von ‚Clean Architecture‘

Der Aufwand, um eine ‚Clean Architecture‘ umzusetzen lohnt sich vor allem bei komplexen Anwendungen, die voraussichtlich über eine längere Zeit gewartet werden müssen, da sie relevante Geschäftsprozesse unterstützen. In der Intralogistik ist hier die Implementierung von Warehouse Management Software / Lagerverwaltungssoftware, also Warehouse Management System oder Materialflusssteuerung, in große Distributionszentren zu nennen. Aufgrund des Höchstmaßes an Flexibilität und Unabhängigkeit aller Komponenten und Prozesse, bietet sich ‚Clean Architecture‘ in manchen Märkten besonders an. Gerade in Anwendungsbereichen, die durch lange Projektlaufzeiten, hohe Komplexitätsgrade und volatile Marktsituationen gekennzeichnet sind, kann das Prinzip enorme Vorteile mit sich bringen. In solchen Wettbewerben stehen laufend fachliche oder technische Veränderungen an, die nicht das gesamte System betreffen, weshalb es von großem Vorteil ist, Verkettungen vermeiden und Geschäftsregeln als zentrales Element einsetzen zu können. ‚Clean Architecture‘ wird oftmals auch in Kombination mit Domain Driven Design oder Context Aware Frontend Architecture eingesetzt, insbesondere in agilen Umgebungen mit Self-contained Systems und Micro-Services.

Zusammenfassung

‚Clean Architecture‘ ist ein Architekturstil für IT-Systeme und -Anwendungen, der dem klassischen Drei-Schichten-Modell entgegensteht, indem die Business-Logik und somit die Geschäftsregeln den Kern des Aufbaus bilden. Die Business-Logik ist dabei völlig entkoppelt und dadurch unabhängig von Frameworks, Datenbanken und Nutzerinterfaces. Dies führt zu einer großen Testfähigkeit in Bezug auf Schnelligkeit und Einfachheit, da die Komponenten anderer Schichten hierfür nicht angefasst beziehungsweise angepasst werden müssen. ‚Clean Architecture‘ bietet sich besonders bei komplexen Anwendungen an, die über längere Zeit laufen und abhängig von sich häufig ändernden Anforderungen dementsprechend oft gewartet, angepasst und verändert werden müssen.

Zurück zur Startseite
Zur Kategorieübersicht
Zum Beitrag ‚Context Aware Frontend Architecture‘