Skip to content

Der Blick auf das große Ganze

Warum auch die beste Architektur mehr als nur sauberen Code benötigt

Eine Gruppe von Menschen die Pflanzen in ihren Händen halten

Foto von feey auf Unsplash

Von der Code-Ebene zur Systemarchitektur

Wir sind fast am Ende angelangt. Heute, am letzten inhaltlichen Tag unseres Clean-Code-Abenteuers (morgen folgt noch ein Schlusswort), heben wir unseren Blick von der Code-Ebene auf das System als Ganzes. Dieser Schritt erfordert ein breiteres Verständnis und die Fähigkeit, aus der Vogelperspektive auf unsere Software zu schauen. Denn selbst wenn jede einzelne Codezeile den Clean-Code-Prinzipien entspricht, garantiert das noch keine langfristig wartbare Systemarchitektur.

Die fundamentalen Systemelemente

In jedem Softwaresystem lassen sich wiederkehrende Elemente identifizieren. Die zwei wichtigsten davon sind Erzeugung und Anwendung. Jedes System muss aus verschiedenen Komponenten zusammengesetzt werden – Services, Repositories, Domain-Objekte, Datenbankverbindungen und viele mehr. Die Erschaffung dieser Komponenten sollte konsequent von ihrer Verwendung in der Geschäftslogik getrennt werden. Dies folgt dem bekannten Single Responsibility Principle (SRP) und dem Konzept der "Separation of Concerns", allerdings auf einer höheren Abstraktionsebene.

Dieses Grundprinzip lässt sich auf nahezu jedes System übertragen. Moderne Frameworks unterstützen uns dabei durch Dependency Injection, wie beispielsweise der Spring Container, der diese Trennung elegant umsetzt.

Cross-Cutting Concerns

Ein weiteres zentrales Beispiel für die Trennung von Konzepten auf Systemebene sind die sogenannten "Cross-Cutting Concerns". Diese Aspekte durchziehen alle Teile und Schichten einer Anwendung und umfassen:

  • Security

  • Performance-Messung

  • Exception Handling

  • Monitoring

  • Kommunikation

  • Logging

Die Herausforderung: Ohne geeignete Strukturierung kann der entsprechende Code die eigentliche Geschäftslogik stark überlagern. Wenn jede zweite Business-Methode eine Log-Ausgabe enthält, liegt ein strukturelles Problem vor. Für solche Fälle nutzen wir typischerweise AOP (Aspect Oriented Programming). In Sprachen wie Go kommen stattdessen oft Middlewares zum Einsatz. Beim Logging kann beispielsweise ein Aspekt implementiert werden, der Methodenaufrufe samt Parametern automatisch protokolliert – meist ausreichend für eine effektive Problemanalyse.

Weitere wichtige Systemaspekte

Im Kontext der Clean-Code-Architektur gibt es noch zahlreiche weitere relevante Themen:

  • Testing-Architektur

  • Architektonische Entscheidungsprozesse

  • Die Verwendung etablierter Standards

  • Domain Specific Languages für System und Architektur

  • und viele mehr

Der Impuls für heute

Meine Empfehlung: Legen Sie regelmäßig eine Pause ein, um Ihr System als Ganzes zu betrachten. Eine einfache Visualisierung kann enorm hilfreich sein und die weitere Programmierung deutlich vereinfachen. Fragen Sie sich, wo Ihre "Cross-Cutting Concerns" liegen, wo Ihre Objekte erzeugt werden und wo Ihre Geschäftslogik angesiedelt ist.

Besonders wertvoll ist die Frage nach konsistenter Terminologie: Sind die verwendeten Begriffe einheitlich und passend zum System? Ein Softwaresystem gleicht einer kleinen Stadt – es besteht aus vielen unterschiedlichen Elementen, und jedes hat einen Namen und eine Rolle. Wenn Sie diese identifizieren und organisieren, wird die Arbeit mit dem System deutlich einfacher und intuitiver.

Author

Sebastian Bergandy
Sebastian Bergandy