Designprinzipien
Designprinzipien sind keine akademischen Regeln.
Sie sind Heuristiken, die helfen, Systeme langfristig:
- wartbar
- testbar
- verständlich
- erweiterbar
- risikoarm
zu gestalten.
Ohne Designprinzipien entsteht Code,
der kurzfristig funktioniert –
aber langfristig teuer wird.
1. Warum Designprinzipien notwendig sind
Software verändert sich.
Anforderungen ändern sich.
Teams ändern sich.
Technologien ändern sich.
Designprinzipien helfen, Systeme so zu bauen,
dass Veränderung nicht zum Risiko wird.
Gute Architektur entsteht aus konsequent angewandten Designprinzipien.
2. Die wichtigsten Prinzipien (praxisorientiert)
Nicht jedes Prinzip ist immer relevant.
Aber einige haben sich über Jahrzehnte bewährt.
2.1 Single Responsibility Principle (SRP)
Eine Einheit sollte genau einen Grund zur Änderung haben.
Konsequenz:
- Kleine, fokussierte Module
- Klare Verantwortlichkeiten
- Geringere Seiteneffekte
Symptome bei Verletzung:
- „God Classes“
- 1000-Zeilen-Services
- Jede Änderung bricht mehrere Tests
2.2 Separation of Concerns
Unterschiedliche Verantwortungen werden getrennt:
- Domänenlogik
- Infrastruktur
- UI
- Datenzugriff
Ohne Trennung entsteht:
- Framework-Abhängigkeit in der Domäne
- Schwer testbarer Code
- Hohe Kopplung
2.3 Dependency Inversion
High-Level-Logik darf nicht von Low-Level-Details abhängen.
Beispiel:
Domäne hängt nicht direkt von:
- HTTP
- Datenbank
- Framework
Sondern von:
- Abstraktionen
Das ermöglicht:
- Testbarkeit
- Austauschbarkeit
- geringere Kopplung
2.4 Open/Closed Principle
Module sollten offen für Erweiterung, aber geschlossen für Modifikation sein.
Praktisch:
- Erweiterbarkeit durch neue Implementierungen
- Keine dauernden Änderungen im Kern
Ziel:
Stabile Kernlogik trotz wachsender Anforderungen.
2.5 KISS (Keep It Simple)
Komplexität ist ein Kostenfaktor.
Komplexität erzeugt:
- Bugs
- Missverständnisse
- Wartungsaufwand
Einfachheit ist kein Stil –
sie ist Risikominimierung.
2.6 YAGNI (You Aren’t Gonna Need It)
Nicht implementieren, was nicht gebraucht wird.
Vorzeitige Abstraktion:
- erhöht kognitive Last
- erschwert Lesbarkeit
- erzeugt unnötige Kopplung
2.7 DRY (Don’t Repeat Yourself)
Wissen darf nicht mehrfach existieren.
Aber Vorsicht:
- Duplizierter Code ≠ dupliziertes Wissen
- Zu frühe Abstraktion kann schädlich sein
DRY bedeutet:
Wissensquelle ist eindeutig – nicht zwingend jede Codezeile.
3. Prinzipien im Konflikt
Designprinzipien sind keine Gesetze.
Sie stehen oft im Spannungsfeld:
- DRY vs. Lesbarkeit
- KISS vs. Erweiterbarkeit
- YAGNI vs. Zukunftssicherheit
- Abstraktion vs. Komplexität
Gutes Engineering bedeutet:
Bewusste Trade-offs treffen – nicht Prinzipien blind anwenden.
4. Designprinzipien als Qualitätshebel
Designprinzipien beeinflussen:
- Testbarkeit
- Änderbarkeit
- Fehlerisolierung
- Lesbarkeit
- Teamgeschwindigkeit
Schlecht geschnittener Code erhöht:
- Technische Schulden
- Review-Aufwand
- Einarbeitungszeit
- Bus-Faktor-Risiko
5. Verbindung zur Architektur
Architekturentscheidungen wirken auf Makroebene.
Designprinzipien wirken auf Codeebene.
Aber:
Makro-Architektur ohne sauberes Micro-Design zerfällt.
Micro-Design ohne klare Architektur fragmentiert.
Beides gehört zusammen.
6. Anti-Pattern: Prinzipien als Dogma
Gefährlich wird es, wenn:
- Prinzipien zu Checklisten werden
- Code nur „theoretisch sauber“ ist
- Abstraktionen ohne Bedarf entstehen
- Architektur wichtiger wird als Produktwert
Designprinzipien sind Werkzeuge.
Kein Selbstzweck.
7. Praktische Leitfragen
Bei jeder relevanten Entscheidung:
- Hat diese Einheit eine klare Verantwortung?
- Kann ich sie isoliert testen?
- Ist die Abhängigkeit notwendig?
- Wird Komplexität reduziert oder erhöht?
- Ist das verständlich für neue Teammitglieder?
Wenn mehrere Antworten „nein“ sind,
liegt oft ein Designproblem vor.
Kerngedanke
Designprinzipien sind keine akademische Theorie.
Sie sind angewandte Risikominimierung.
Sie reduzieren:
- technische Schulden
- Wartungskosten
- Fehleranfälligkeit
- Team-Reibung
Und sie ermöglichen das, was Software langfristig braucht:
Veränderbarkeit.