Clean Architecture

Im Laufe der Zeit wurde die Software-Architektur auf viele verschiedene Arten definiert. Formale Definitionen besagen, dass es sich um die grundlegende Zusammensetzung eines Systems handelt, oder um die Art und Weise, wie die Komponenten der obersten Ebene zusammengesetzt sind. Andere haben gesagt, dass es sich um die Entscheidungen handelt, von denen sie sich wünschen, dass sie zu Beginn eines Projekts richtig getroffen worden wären. Letztendlich ist die Architektur aber alles, was wichtig ist, und das ist von System zu System unterschiedlich.

Layercake of frozen music

Die Software-Architektur ist wichtig, weil sie zur ständigen Weiterentwicklung eines Systems beiträgt, ohne es zu teuer oder unerschwinglich zu machen. Clean Architecture wurde erstmals 2012 von Robert C. Martin in einem Blogpost vorgestellt und zielt darauf ab, genau das zu tun. Was also ist Clean Architecture, wann und wo sollte sie eingesetzt werden?

Was ist Clean Architecture?

Clean Architecture ist eine Software­entwurfs­philosophie, die darauf abzielt, die Trennung von Belangen in einem System zu maximieren und die Verwendung von sauberem Code und SOLID-Grundsätzen zu fördern. Die Trennung der Belange wird durch Aufteilung der Software in Schichten erreicht. Ein System, das nach einer sauberen Architektur aufgebaut ist, …

  • ist unabhängig von Frameworks, da diese hinter Schnittstellen versteckt sind und leicht ausgetauscht werden können.

  • ist testbar, da die Geschäftsregeln nicht von einer anderen Schicht abhängig sind.

  • ist unabhängig von einer Benutzeroberfläche oder Datenbank, da diese wie die Frameworks einfach ausgetauscht werden können.

Grafische Darstellung. Rechts ein Kreisdiagramm. Im lilafarbenem Zentrum ist das Wort Entities. Darum bildet sich ein roter Ring mit dem Wort Use Cases. Dieser wird eingeschlossen von einem orangenem Ring in dem Controllers, Presenters und Gateways steht. Der äußerste Ring ist blau gefärbt und trägt die Begriffe Devices, Web, UI, Ext. Interfaces und DB in sich. Links neben dem Kreisdiagramm findet sich die Legende. Lila steht für Enterprise Business Rules. Rot für Application Business Rules, orange für Interface Adapters und blau für Frameworks & Drivers. Darunter befindet sich noch eine Mindmap. Ganz oben links ist ein oranges Feld in dem Presenter steht. Dieses deutet mit einem Pfeil auf das Feld rechts daneben in dem "Use Case Output Port" steht. Dieses Feld führt zu dem darunter welches "Use Case Integrator" enthält. Unter dem Presenterfeld ist die Beschriftung "Flow of Control". Darunter ist ein Feld mit "Controller" zu sehen. Das Controllerfeld führt rechts mit einem Pfeil zu einem Feld mit "Use Case Input Port".

Clean Architecture Schichten

Die vier oben gezeigten Schichten sind natürlich nicht die einzigen, die es geben kann, je nach Problemstellung können weitere Schichten hinzugefügt werden. Das einzige, was dabei beachtet werden sollte, ist die Abhängigkeitsregel. Diese Regel besagt, dass Abhängigkeiten nur nach innen gerichtet sein dürfen. Innere Schichten sollten niemals von den äußeren Schichten abhängen.

Entitäten sind die innerste Schicht, sie kapseln Geschäftsregeln oder Dinge, die für eine Anwendung immer wahr oder statisch sein werden. Entitäten können einfach Objekte mit Methoden oder einfache Datenstrukturen und Funktionen sein. Diese Schicht wird sich während der Lebensdauer einer Anwendung wahrscheinlich am wenigsten ändern und sollte von Änderungen in anderen Schichten nicht betroffen sein.

Sie implementieren die Anwendungsfälle des Systems, indem sie mit Entitäten interagieren und Daten zwischen ihnen austauschen, um die entsprechenden Ziele zu erreichen. Im Wesentlichen legen sie fest, welche Interaktionen mit dem System möglich sind.

Neugierig geworden? Jetzt weiterlesen.

Hier können Sie kostenfrei den vollständigen UXMA-Trendreport 2022 herunterladen und von weiteren spannenden Artikeln profitieren!

Insights

Gemeinsam etwas Großes starten?