Erweiterbare Architektur: Was Wachstum im Code wirklich bedeutet
Erweiterbarkeit ist kein Zufall und kein Versprechen — sie ist das Ergebnis von Entscheidungen, die früh getroffen werden müssen.
„Das System soll mit uns wachsen." Diesen Satz höre ich oft. Er klingt nach einer Anforderung, ist aber eigentlich eine Hoffnung. Erweiterbarkeit entsteht nicht von selbst — sie ist das Ergebnis konkreter Entwurfsentscheidungen, die getroffen werden müssen, bevor das Wachstum beginnt.
Was Erweiterbarkeit nicht ist
Erweiterbarkeit ist nicht dasselbe wie Flexibilität. Flexibel ist ein System, das sich leicht ändern lässt — auch in Richtungen, die niemand vorhergesehen hat. Das klingt gut, führt aber häufig zu Architektur, die zu viel kann und dabei nichts sauber tut.
Erweiterbarkeit ist zielgerichteter: Das System ist so gebaut, dass neue Fähigkeiten hinzukommen können, ohne dass Bestehendes verändert werden muss. Das ist ein Unterschied, der im Alltag viel ausmacht.
Das Kernprinzip: Grenzen vor Offenheit
Ein erweiterbares System hat klare Grenzen. Nicht weil es starr sein soll, sondern weil klare Grenzen definieren, wo etwas hinzugefügt werden kann — und was dabei unverändert bleibt.
In der Praxis bedeutet das: Module, die eine einzige Aufgabe haben. Schnittstellen, die stabil sind, auch wenn sich die Implementierung dahinter ändert. Abhängigkeiten, die explizit und gerichtet sind — nicht implizit und zirkulär.
KI-generierter Code tendiert in die andere Richtung. Er ist oft funktional korrekt, aber grenzenlos: Abhängigkeiten entstehen dort, wo sie gerade gebraucht werden. Zustand wird dort abgelegt, wo er erreichbar ist. Das funktioniert im Moment der Entstehung. Beim nächsten Feature fängt es an zu schmerzen.
Wann Erweiterbarkeit investiert werden muss
Nicht sofort. In frühen Phasen ist Geschwindigkeit das richtige Kriterium. Wer mit KI-Tools baut, sollte das tun — das ist der Vorteil dieser Werkzeuge.
Der Punkt, an dem sich das Verhältnis umkehrt, ist gut erkennbar: wenn Änderungen länger dauern als sie sollten. Wenn eine neue Funktion Regressionstests aus einem anderen Bereich zum Scheitern bringt. Wenn niemand mehr weiß, was passiert, wenn man an dieser Stelle etwas verändert.
Das ist der Moment für die Diagnose — nicht für einen Neubau, sondern für eine gezielte Intervention: Grenzen nachziehen, Schnittstellen definieren, Tests dort einziehen, wo das System zukünftig wachsen soll.
Was am Ende zählt
Ein System ist nicht dann erweiterbar, wenn es sich theoretisch erweitern ließe. Es ist erweiterbar, wenn das nächste Feature tatsächlich ohne Kollateralschäden hinzugefügt werden kann.
Das ist das Kriterium, an dem ich Architektur messe. Nicht Eleganz. Nicht Vollständigkeit. Sondern: Kann das Team in sechs Monaten noch vernünftig weiterarbeiten?
Wenn die Antwort heute nicht sicher „Ja" ist, lohnt es sich, das herauszufinden — bevor der Druck steigt.