Was ist eine der unangenehmsten Erfahrungen für einen Entwickler? Viele werden sofort sagen: Änderungen an bestehendem Code durchführen, den man nicht selbst entwickelt hat und der am besten auch nicht dokumentiert und Unit-getestet ist.

Persönlich habe ich in einem hoch kritischen Projekt genau diese Erfahrung machen müssen. Selbst kleinste Änderungen an fremden Komponenten, die harmlos hätten sein müssen, sorgten dafür, dass etliche Unit-Tests (wenn vorhanden) fehlschlugen. Aufgaben, die an sich nur einige wenige Stunden hätten dauern sollen, führten zu tagelangen Reverse-engineering-Sessions. Ganz zu schweigen davon, dass nötige Refactorings nicht durchgeführt werden konnten, weil sie Querwirkungen auf die komplette Anwendung von UI bis Datenbank und einen anschließenden vollständigen Regressionstest bedeutet hätten.

Dieser Zustand änderte sich nach und nach, als sich mein Team darauf einigte, mehrere neue Architekturansätze zu verfolgen. Einer der wichtigsten davon ist der Ansatz der Clean Architecture.

Clean Architecture hat unser Team letztlich in die Lage versetzt, stabile, gut wartbare und leicht änderbare Software zu produzieren.

Nachfolgend möchte ich Ihnen diesen Ansatz erläutern.

Was ist Clean Architecture?

Die Geschäftsregeln (Business Rules) einer Anwendung, egal wie groß, bilden den eigentlichen Wert einer Anwendung. Das hat mehrere Implikationen für deren Umsetzung: Sie sollten möglichst einfach und verständlich umsetzbar sein, sie sollten möglichst unabhängig von technischen Rahmenbedingungen zu pflegen sein und der Testaufwand bei Änderungen sollte möglichst niedrig sein.

Clean Architecture ermöglicht uns genau das, nämlich eine von Frameworks, der UI und der Datenbank unabhängige Umsetzung sowie eine bessere Testbarkeit der Business Rules.

Für die Entwicklung im Rahmen der Clean Architecture bedeutet dies grundlegend, dass die Business Rules von allen externen Faktoren unabhängig gemacht werden sollen, sodass Änderungen an „unwesentlichen“ Teilen der Software diese unberührt lassen.

Erreicht wird diese Unabhängigkeit durch eine Aufteilung der Software in verschiedene Schichten, die nur auf eine fest definierte Art und Weise miteinander kommunizieren dürfen. 

Diese Schichten werden in innere und äußere Schichten unterteilt. Keine innere Schicht besitzt dabei Wissen über die Existenz von Schichten, die weiter außen liegen als sie selbst. Damit ist automatisch der Kontrollfluss vorgegeben. Eine Kommunikation kann nur von außen nach innen erfolgen und nicht umgekehrt.

Der Kontrollfluss richtet sich von den äußeren Schichten nach innen. Zwischen den Schichten werden Nachrichten in Form von einfachen, isolierten Datenstrukturen wie beispielsweise DTOs [Data Transfer Objects] ausgetauscht.

Fazit

Wenn man die Clean Architecture als Werkzeug ansieht, um eine gute Schichtentrennung und damit eine leichtere Änderbarkeit der Software zu erreichen, ist es eine meines Erachtens sehr gute Vorgehensweise, die die Qualität des entwickelten Produktes steigert.

Horrorszenarien wie das in der Einleitung angesprochene habe ich in mehreren Folgeprojekten, die auf Clean Architecture basierten, nicht mehr erlebt.

Tatsächlich hat mein Team es geschafft, eine sehr stabile Architekturgrundlage zu etablieren. Teammitglieder sind ohne nennenswerte Einarbeitungszeit in der Lage, von der Entwicklung einer Applikation, die darauf beruht, in ein anderes Entwicklungsteam zu wechseln und dort Features zu entwickeln. Und das, ohne dass Unit-Tests explodieren.

Allein diese Tatsache spricht aus meiner Sicht stark für diesen Ansatz.

Ich freue mich auf Ihre Fragen und Anmerkungen zum Thema „Softwarearchitektur“ und Clean Architecture. Auch bin ich sehr gespannt auf Ihre Meinung über Clean Architecture als modernen Architekturansatz.