Architektur-Fitness-Functions: den Rahmen prüfbar machen, bevor er erodiert
Architekturregeln, die nur in einer Präsentation stehen, erodieren immer. Neu ist das Tempo: Was früher über Jahre passierte, passiert jetzt über Monate, weil deutlich mehr Code entsteht und niemand ihn vollständig liest.
Fitness-Functions sind automatisierte Tests über Architekturaussagen: erlaubte Abhängigkeitsrichtungen, Technologie-Isolation, Konventionen mit Bedeutung. Sie laufen in der normalen Pipeline und machen aus einem Architekturverstoß einen roten Build statt einer Reviewdiskussion. In gewachsenen Codebasen arbeitet man mit einer Ausgangsliste bestehender Verstöße, die nur schrumpfen darf. Bei hohem Änderungsvolumen sind sie die einzige Vorgabeform, die ohne zusätzliche Aufmerksamkeit mithält.
Was eine Fitness-Function ist
Ein automatisierter Test, der eine Architekturaussage prüft: Modul A darf Modul B nicht kennen. Die Domänenschicht darf keine Abhängigkeit zum Web-Rahmenwerk haben. Kein Paket außerhalb der Persistenzschicht darf SQL enthalten. Es sind gewöhnliche Tests, die in derselben Pipeline laufen wie alle anderen — der Unterschied ist, worüber sie eine Aussage treffen.
Die drei Regeln, die fast überall zuerst passen
Erstens erlaubte Abhängigkeitsrichtungen zwischen den Hauptmodulen. Zweitens Technologie-Isolation: Rahmenwerke, Datenbanktreiber und externe Bibliotheken nur in den dafür vorgesehenen Bereichen. Drittens Namens- und Ablagekonventionen, soweit sie eine Bedeutung tragen. Diese drei fangen den größten Teil der schleichenden Vermischung ab und lassen sich an einem Tag einführen.
Warum das bei erhöhtem Volumen entscheidend wird
Ein Assistenzsystem kennt die Struktur, die es im Repository sieht — nicht die, die gemeint war. Wo Grenzen nur in Köpfen existieren, entsteht innerhalb weniger Monate mehr Verflechtung als vorher in Jahren. Die Fitness-Function ist die einzige Form von Architekturvorgabe, die mit dieser Geschwindigkeit mithalten kann, weil sie keine Aufmerksamkeit verbraucht.
Der schwierige Teil: der Bestand
In einer gewachsenen Codebasis schlägt jede sinnvolle Regel sofort hundertfach an. Der übliche Umgang damit ist eine Ausgangsliste: bestehende Verstöße werden festgeschrieben und akzeptiert, neue blockiert. Die Liste darf nur schrumpfen, nie wachsen — das ist die eigentliche Regel, und sie lässt sich ebenfalls automatisch prüfen.
Was das für die Zusammenarbeit ändert
Architekturdiskussionen verlagern sich vom Pull Request in den Regelsatz. Wer eine Grenze für falsch hält, ändert die Regel — mit Begründung, Review und Historie. Das ist langsamer als eine Bemerkung im Review und deutlich haltbarer, weil die Entscheidung danach für alle gilt und nicht nur für den einen Fall.
Häufige Fragen
Welche Werkzeuge gibt es dafür?
ArchUnit für Java und .NET, dependency-cruiser oder eslint-Regeln für JavaScript und TypeScript, import-linter für Python, sowie die Modulgrenzen-Prüfungen gängiger Build-Werkzeuge. Für die ersten drei Regeln reicht in der Regel das, was die Sprache ohnehin mitbringt.
Wie geht man mit den Verstößen im Bestand um?
Über eine Ausgangsliste: Der heutige Zustand wird festgeschrieben, neue Verstöße blockieren. Die Liste darf nur kleiner werden — auch das lässt sich prüfen. So wird die Regel sofort wirksam, ohne dass zuerst die Altlast beseitigt werden muss.
Wer entscheidet über die Regeln?
Dieselbe Runde, die vorher Architekturentscheidungen getroffen hat — nur ist das Ergebnis jetzt ausführbar. Wichtig ist, dass eine Regeländerung denselben Weg geht wie eine Codeänderung: Vorschlag, Begründung, Review, Historie.
Bremsen Fitness-Functions nicht die Entwicklung?
Sie bremsen die Fälle, die später teuer werden. Der übliche Effekt ist umgekehrt: Weil Architekturfragen nicht mehr im Review verhandelt werden, gehen Pull Requests schneller durch. Diskutiert wird über die Regel, nicht über jeden Einzelfall.
Rechnen Sie Ihre Review-Lücke aus.
Vierzehn Fragen, fünf Minuten. Ihre Zahlen, kein Login.
AI Engineering Review ansehen →
