Architektur ist kein Luxus: wie man Dependency Hell und den Skalierbarkeits-Kater vermeidet

Architektur-Entscheidungen fühlen sich am Anfang eines Projekts unwichtig an — es gibt ja noch kaum etwas, das brechen könnte. Genau das macht sie so folgenreich: Was in den ersten zwei Wochen falsch angelegt wird, kostet in den nächsten zwei Jahren ein Vielfaches an Zeit, es wieder geradezuziehen.

Woran man merkt, dass die Struktur nicht mehr trägt

Die Symptome sind selten abstrakt. Eine kleine Änderung, die plötzlich fünf Dateien berührt, die eigentlich nichts miteinander zu tun haben sollten. Ein Test, der nicht mehr „ein Verhalten prüft", sondern erstmal zehn Zeilen Mocking braucht, nur um überhaupt zu laufen. Ein „kann ich kurz X anpassen" aus dem Kundengespräch, das sich beim Blick in den Code als Tagesaufgabe entpuppt. Das sind keine Einzelfälle — das ist die Struktur, die Alarm schlägt.

Dependency Hell entsteht selten auf einen Schlag

Niemand baut absichtlich zirkuläre Abhängigkeiten. Sie entstehen Schritt für Schritt: Modul A importiert eine Hilfsfunktion aus Modul B, weil es schnell ging. Später braucht B etwas aus A. Beide lassen sich jetzt nicht mehr unabhängig testen, nicht mehr unabhängig updaten, und ein Versions-Bump in einer dritten Abhängigkeit reißt beide gleichzeitig mit.

// Modul A
import { formatPrice } from '../shop/helpers';

// Modul B (shop/helpers)
import { currentUser } from '../auth';

// später: auth importiert etwas aus A → Kreis geschlossen,
// keins der drei Module lässt sich mehr isoliert verstehen

Die Regel, die sich bei mir bewährt hat: Abhängigkeiten dürfen nur in eine Richtung zeigen. Wenn ein „unteres" Modul etwas aus einem „oberen" braucht, ist das kein Implementierungsdetail, sondern ein Signal, dass die Grenze falsch gezogen wurde.

Skalierbarkeit ist eine Entscheidung, kein Automatismus

Ob ein System bei drei Kunden noch genauso funktioniert wie bei dreißig, hängt nicht davon ab, wie viel Server-Leistung man dazukauft, sondern davon, ob Grenzen von Anfang an klar gezogen wurden: Wo lebt Mandanten-Trennung, wo Berechtigungslogik, wo domänenspezifisches Wissen. Bei einer Handvoll Nutzern verzeiht fast jede Struktur ihre Schwächen. Ab einer gewissen Größe zeigt sich gnadenlos, ob sauber getrennt wurde oder nur zufällig funktioniert hat.

Der Gegenpol: Über-Architektur ist genauso teuer

Das Gegenteil ist kein Ausweg. Sechs Abstraktionsschichten für ein Formular mit drei Feldern lösen kein Problem, das existiert — sie erschaffen eins: Niemand findet mehr, wo die eigentliche Logik steckt. Gute Architektur ist nicht „möglichst viel Struktur", sondern möglichst wenig Struktur, die genau das trägt, was gebraucht wird.

Das eine Prinzip, das über Projekte hinweg trägt: Grenzen früh und bewusst ziehen, auch wenn es sich nach Zeitverschwendung anfühlt, solange noch alles klein ist. Der Moment, in dem sich das auszahlt, kommt garantiert — meistens genau dann, wenn am wenigsten Zeit dafür ist, es nachträglich zu reparieren.