Gute Software-Architektur ist nicht kostenlos. Sie kostet Zeit, Aufmerksamkeit und Disziplin – vor allem am Anfang.
Wer sauber trennt, wer bewusst zwischen Kern, Grenze und Peripherie unterscheidet, schreibt nicht den kürzesten Code, sondern den belastbarsten.
Warum gute Architektur sich zuerst teuer anfühlt
Am Anfang wirkt saubere Architektur oft wie ein Umweg:
- mehr Dateien statt einer
- mehr Ordner statt „einfach schnell“
- mehr Nachdenken, bevor man tippt
- weniger sichtbarer Fortschritt
Für ein einmaliges Skript wäre das Overengineering. Für ein System, das wächst, sich ändert oder integriert wird, ist es eine Investition.
1. Der stabile Kern
Im Kern eines Systems lebt die Wahrheit der Domäne:
- wohldefinierte Objekte
- klare Invarianten
- konsistentes Verhalten
- keine Abhängigkeit von Technikdetails
Hier gelten strenge OOP-Regeln. Hier darf es keine JSON-Strukturen, HTTP-Fehler oder API-Eigenheiten geben.
Der Kern ist langweilig – und genau das ist seine Stärke.
2. Die strenge Grenze
Zwischen Kern und Außenwelt braucht es eine harte Grenze:
- Facades
- Use-Cases
- Anti-Corruption Layer
An dieser Stelle passiert die Übersetzung: von dict zu Objekt, von chaotischen Daten zu stabiler Domäne.
Diese Grenze ist bewusst streng. Alles, was sie überschreitet, wird normalisiert oder abgewiesen.
3. Die volatilen Ränder
Außen ist die Realität:
- APIs ändern sich
- Daten fehlen oder kommen doppelt
- Netzwerke sind langsam oder instabil
- Drittsysteme halten sich nicht an Verträge
Beispiele kennt jeder, der integriert:
- Webhooks werden mehrfach gesendet (Withings lässt grüßen)
- Events kommen „at least once“
- Felder tauchen plötzlich nicht mehr auf
Diese Volatilität ist normal. Aber sie gehört nicht in den Kern, sondern in Adapter, Provider und Decorators.
Design Patterns als Schutzmechanismen
Design Patterns sind kein Selbstzweck. Sie sind Werkzeuge zur Schadensbegrenzung:
- Factory schützt vor harter Kopplung
- Facade schützt den Kern vor externer Komplexität
- Decorator schützt vor Feature-Wildwuchs
- Fallback / Retry / Cache schützen vor instabilen Rändern
- MVC schützt vor Verantwortungschaos
Man bezahlt mit Abstraktion – und erhält Wartbarkeit, Austauschbarkeit und Ruhe.
Die versteckten Einsparungen
Der eigentliche Gewinn zeigt sich nicht heute, sondern später:
- Änderungen bleiben lokal
- neue Provider ersetzen alte, ohne das System zu zerlegen
- Features fügen sich ein, statt Seiteneffekte zu erzeugen
- Tests werden möglich, ohne Infrastruktur mitzuschleppen
- Debugging passiert im Code – nicht nachts auf dem Server
Gute Architektur spart keine Zeit beim Schreiben. Sie spart Zeit beim Verstehen, Erweitern und Reparieren.
Der mentale Effekt
Ein oft unterschätzter Aspekt: Struktur schafft Ruhe.
Wenn klar ist, was Controller dürfen, was Services dürfen, was der Kern darf – und was ausdrücklich draußen bleiben muss – dann denkt man nicht mehr über den Ort nach, sondern über den Inhalt.
Das reduziert kognitive Last – und Fehler.
Fazit
Gute Architektur kostet am Anfang mehr. Aber sie verhindert, dass man später:
- aus Angst vor Änderungen nichts mehr anfasst
- Hotfixes im laufenden Betrieb baut
- Fehler jagt, die überall und nirgendwo sind
- Systeme pflegt, die man selbst nicht mehr versteht
Schlechte Architektur ist billig – bis man sie ändern muss.
Projekt auf GitHub: https://github.com/eddy-san/affiliate-app