Fitness Functions
Eine Fitness Function prüft fortlaufend, ob eine wichtige Architektureigenschaft eingehalten wird. Sie kann statisch, dynamisch oder anhand messbarer Betriebsdaten ausgeführt werden.
- RegelDie Eigenschaft, die gelten soll.
- PrüflaufAutomatisch bei jeder Änderung.
- FundstelleVerstoß mit Ort melden.
Einordnung
Warum das wichtig ist
Architekturregeln, die nur im Kopf oder Dokument stehen, werden unbemerkt verletzt. Eine automatisierte Prüfung macht Verstöße sofort sichtbar. Wie Abweichungen langfristig entstehen, beschreibt Architektur-Erosion.
Dieser Baustein behandelt automatisierte Eigenschaftsprüfungen. Architektur-Erosion beschreibt Abweichungen; Architekturreview bewertet Entwurf und Risiken im Kontext.
Auf einen Blick · Architekturregeln automatisch prüfen
Prüflauf für Modulzugriffe
Der Shop hält Abhängigkeiten zwischen Bestell-, Versand- und Rechnungsmodul innerhalb definierter Modulverträge. Ein automatischer Test markiert unerlaubte Datenbankzugriffe.
So liest du das Bild
- Regel Die Zeile „Module greifen nur über Verträge aufeinander zu“ oberhalb der Änderungen.
- Prüflauf Das Ergebnis „Build grün“ oder „Build rot“ nach Auswahl einer Änderung.
- Fundstelle Die Meldung bei „Build rot“ nennt Modul und Zugriff, etwa Versand auf Bestelltabelle.
RegelModule greifen nur über Verträge aufeinander zu.
Build rotBuild rot: Direktzugriff auf Bestelltabelle gemeldet, Fundstelle im Versandmodul genannt.
Nutzen & Grenzen
Hilft, wenn
- Viele Änderungen und Beteiligte profitieren von früh sichtbaren Strukturprüfungen.
- Kritische Qualitätseigenschaften benötigen wiederholbare Nachweise über Commit-, Release- oder Betriebsgrenzen hinweg.
Grenzen
- Eine bestandene Regel belegt nur ihren Messbereich; offene Eigenschaften brauchen unabhängige Nachweise.
- Überholte Schwellen blockieren sinnvolle Änderungen; Annahmen und Ausnahmen gehören mit den Verantwortlichen regelmäßig geprüft.
- Importregeln sehen keine Daten- und Laufzeitkopplung; wie Abweichungen entstehen, zeigt Architektur-Erosion.
In der Praxis
- Eigenschaft operationalisieren. Definiere eine überprüfbare Regel oder Messung samt Systembereich und gewünschtem Verhalten. Benenne, welche Schlussfolgerung ein Bestehen erlaubt. Das Ergebnis ist eine konkrete Fitnessaussage mit messbarem Geltungsbereich.
- Prüfverfahren und Rhythmus wählen. Ordne Prüfungskosten einem passenden Laufzeitpunkt zu und lege Schwelle, Umgebung und Datengrundlage fest. Stelle sicher, dass Fehlermeldungen für Verantwortliche interpretierbar sind. Damit wird Rückmeldung wirksam und verhältnismäßig.
- Befund mit einer Maßnahme verknüpfen. Zeige für jedes Ergebnis die verletzte Regel, den Messbereich und die fachliche Folge. Wenn ein Modulzyklus auffällt, prüfe die Änderungshistorie mit Software Analytics, bevor du eine Fitness-Regel gegen den bestätigten Zugriff absicherst.
- Ausnahmen und Regeländerungen pflegen. Weise Sonderfälle mit Besitzer, Frist und Ersatznachweis aus. Prüfe die Regel, wenn sich Qualitätsziel oder Architektur verändert. Das Ergebnis ist ein aktueller Prüfvertrag mit sichtbaren offenen Bereichen.
Ausführliche Erklärung lesen
Eine Fitness Function übersetzt eine Architektureigenschaft in eine wiederholbare Prüfung. Statische Regeln können Abhängigkeiten kontrollieren; Laufzeitprüfungen können Antwortverhalten oder Wiederherstellung messen. Messverfahren, Umfang und Schwelle bestimmen, welche Aussage ein Ergebnis trägt. Die Prüfungen konkretisieren Qualitätsattribute und helfen, Architektur-Erosion früh zu erkennen.
Prüfungen unterscheiden sich in Kosten und Rhythmus: schnelle Regeln können pro Änderung laufen, aufwendige Last- oder Restoreproben regelmäßig. Ein Ergebnis deckt nur den festgelegten Messbereich ab. Ausnahmen brauchen Besitzer und Ablauf; Architekturregeln werden aktualisiert, wenn ihre Annahmen sich ändern. So entsteht automatisierte Rückmeldung ohne den Anspruch, jede architektonische Qualität vollständig zu beweisen. Schwellenwerte benötigen einen fachlichen Bezug und eine verständliche Meldung. Falsch positive Befunde erzeugen Umgehungen, während falsch negative Befunde eine Verschlechterung zu spät zeigen. Jede Prüfung sollte den Regelverstoß und seine Folge für Änderung oder Freigabe verständlich sichtbar machen.
Der Begriff stammt aus „Building Evolutionary Architectures“ von Neal Ford, Rebecca Parsons und Patrick Kua.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Welche Ergebnisse zeigen „Rechnung liest Bestelltabelle per eigener Abfrage“ und „Bestellung ändert eigene Tabelle intern“?
Lösung mit Begründung ansehen
Die erste Änderung ergibt „Build rot“, die zweite „Build grün“.
AnwendenAuf eine neue Lage übertragen
Das Versandmodul soll den Bestellstatus ändern. Wie bleibt der Build grün?
Lösung mit Begründung ansehen
Der Statuswechsel wird über den Bestellvertrag angefordert, statt direkt in die Bestelltabelle zu schreiben.
BewertenEine Alternative abwägen
Der Prüflauf soll nur warnen, nicht den Build stoppen. Was spricht dafür, was dagegen, was empfiehlst du?
Lösung mit Begründung ansehen
Vorteil: stört den Ablauf weniger. Nachteil: Warnungen werden übergangen, Verstöße sickern ein. Empfehlung: Build stoppen, bekannte Altfälle als dokumentierte Ausnahmen führen.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Governing data products using fitness functions (öffnet in neuem Tab)Zeigt überprüfbare Architekturziele und automatisierte Fitness Functions am Beispiel von Datenprodukten.
- ArchUnit – User Guide (öffnet in neuem Tab)Zeigt ausführbare Regeln für Abhängigkeiten, Schichten und Architekturkonformität.
- Thoughtworks – Fitness function-driven development (öffnet in neuem Tab)Erklärt kontinuierliche Rückmeldung über Architekturkonformität durch ausführbare Fitness Functions.
- Markus Harrer · Software Analytics (öffnet in neuem Tab)Softwaredaten als Grundlage für Fragen, Untersuchungen und fundierte Verbesserungen.