Clean Architecture im Web

Was ist eigentlich “Clean Architecture” ? Dabei handelt es sich um einen Softwarearchitekturstil, der ursprünglich von Robert C. Martin, dem Autor von Clean Code, entwickelt wurde.

Eine gute Architektur ist wesentlich für den Aufbau einer skalierbaren, modularen und wartbaren Anwendung. Unterschiedliche Softwarearchitekturen, können sich in den Details der Implementierung unterscheiden – aber verfolgen alle das gleiche Ziel: Seperation of Concerns – Aufteilung der unterschiedlichen Funktionalitäten in mehrere Schichten.

Das Hauptziel von “Clean Architecture” ist es, den Code unter Kontrolle zu halten. Dabei wird das Konzept verfolgt, dass der Anwendungscode – der sich unwahrscheinlich ändert – ohne direkte Abhängigkeiten geschrieben werden muss.

Das bedeutet, wenn ich beispielsweise meine Benutzeroberfläche oder meine Datenbank ändere, soll der Kern des Systems (Domäne, Business Rules) nicht geändert werden – somit sind sämtliche externe Abhängigkeiten vollständig ersetzbar.

Überblick

In der “Clean Architecture” repräsentieren der Domain und der Applikation Layer, den Kern der Anwendung.

Der Domain Layer enthält die Enterprise Logik und der Application Layer die Business Logik. Die Enterprise Logik kann von meheren Layern gemeinsam genutzt werden, hingegen die Business Logik wird normalerweise nur innerhalb des Systems verwendet. Der Kern ist unabhängig vom Datenzugriff und Infrastrukturbelangen. Dies wird durch Schnittstellen/Interfaces und Abstraktionen innerhalb und außerhalb des Kerns erreicht.

Vorteile von Clean Architecture

• Unabhängig von Datenbank und Frameworks
• Unabhängiger Presentation Layer – Man kann bspw. jederzeit das UI ändern, ohne den Rest des Systems oder die Business Logik ändern zu müssen
• Sehr gut testbar, speziell der Kern der Awendung, also Domain Models und Application Business Rules.

Eine Implementierung der “Clean Architecture” in .NET kann folgendermaßen aufgebaut sein:

API

• Controllers: API Controller

Application

• Converters: Konvertieren Dtos und Entities
• Dtos
• UseCases
  • Countries
    • Commands
      • command, handler, validator
    • Queries
      • query, handler, validator

Infrastructure

• Persistence (Data)
• Repository Implementierungen

Domain

• Entities
• Enums
• Repository Abstraktionen (Interfaces)

Die Implementierung dieses Beispiels verwendet die Bibliotheken MediatR für das Mediator Pattern und FluentValidations zur Validierung der Requests.

Der Beispielcode für diesen Artikel kann in diesem GitHub Repository gefunden werden.