Architektur-Erosion
Architektur-Erosion entsteht, wenn Änderungen vereinbarte Grenzen schrittweise unterlaufen. Baselines und Prüfregeln machen neue Abweichungen gegenüber dem bekannten Zustand sichtbar.
- BaselineDer bekannte Ausgangszustand.
- Neue AbweichungAlles über der Baseline.
- AbbauBekannte Pfade mit Termin entfernen.
Einordnung
Warum das wichtig ist
Architekturgrenzen verschwinden selten durch eine große Entscheidung, sondern durch viele kleine Abkürzungen. Ohne Baseline lassen sich neue Verstöße nicht von alten trennen, und der Abbau bleibt folgenlos.
Dieser Baustein behandelt Erkennen und kontrolliertes Abbauen von Abweichungen. Fitness Functions automatisieren ausgewählte Regeln; Modulgrenzen definieren den Bezugspunkt.
Auf einen Blick · Geplante und gewachsene Wege
Direktzugriffe mit und ohne Prüfung
Versand besitzt eine Baseline mit zwei bekannten direkten Bestellzugriffen. Eine Prüfung markiert jede neu hinzukommende Abhängigkeit; die bekannten Pfade haben Verantwortliche und Abbaustichtag.
So liest du das Bild
- Baseline Woche 0: „Direktzugriffe“ zeigt 2, „Neue unbemerkt“ zeigt 0.
- Neue Abweichung Mit Schalter „Prüfung markiert neue Zugriffe“ bleibt „Neue unbemerkt“ bei 0.
- Abbau Woche 8 mit Prüfung: „Direktzugriffe“ sinkt am Abbaustichtag von 2 auf 1.
Nutzen & Grenzen
Hilft, wenn
- Häufige kleine Änderungen können Modulabhängigkeiten und Zuständigkeiten schrittweise ausweiten.
- Historische Grenzverletzungen lassen sich mit Besitzer und messbarem Abbauziel gezielt bearbeiten.
Grenzen
- Importprüfungen sehen nur statische Beziehungen; Datenzugriffe und reale Aufrufpfade ergänzen sie, wie bei Fitness Functions.
- Veraltete Regeln verhindern sinnvolle Strukturänderungen; sie werden begründet und mit der fachlichen Verantwortung angepasst.
- Eine Baseline ohne Abbaustichtag verfestigt die Altlast; sie ordnet Einträge den Technischen Schulden zu.
In der Praxis
- Zielstruktur benennen. Definiere erlaubte Abhängigkeiten, Datenverantwortung und relevante Grenzen für die betrachteten Module. Begründe jede Regel über ihre beabsichtigte Wirkung. Das Ergebnis ist ein überprüfbarer Bezugspunkt für tatsächliche Beziehungen.
- Ist-Zustand mit Hinweisen untersuchen. Vergleiche Änderungshäufigkeit und gemeinsame Änderungen als Suchsignale und prüfe konkrete Commits samt fachlichem Kontext über Software Analytics. Kombiniere den Befund mit Importanalyse, Datenzugriffen und Laufzeitpfaden; trenne neue Verstöße von historischen Abweichungen und weise Auswirkungen sowie Besitzer aus.
- Abweichungen abbauen oder Regel ändern. Plane einen begrenzten Schritt, verhindere neue unerwünschte Beziehungen und prüfe die Wirkung erneut. Bei legitimer fachlicher Änderung passe auch die Zielstruktur an. Das Ergebnis hält Durchsetzung und Weiterentwicklung in Einklang.
Ausführliche Erklärung lesen
Architektur-Erosion entsteht, wenn kleine Änderungen Beziehungen, Datenzugriffe oder Verantwortlichkeiten jenseits beabsichtigter Grenzen hinzufügen. Zyklen, direkte Fremdzugriffe und duplizierte Regeln können spätere Änderungen oder Fehler über mehrere Bereiche ausbreiten. Messregeln und Baselines aus Fitness Functions machen einen Teil davon erkennbar; klare Modulgrenzen definieren den Bezugspunkt.
Statische Analysen erfassen Importe, während Laufzeitaufrufe und gemeinsame Daten zusätzliche Untersuchung benötigen. Vorhandene Verstöße lassen sich einordnen und schrittweise abbauen; neue Abweichungen können früh signalisiert werden. Regeln bleiben überprüfbare Entwurfsannahmen. Bei bewusst veränderter fachlicher Verantwortung werden Zielstruktur und Prüfungen gemeinsam aktualisiert, damit die Regeln die neue Grenze passend abbilden. Eine Baseline hält den bekannten Zustand fest und macht neue Verstöße unterscheidbar. Ein verantwortlicher Besitzer und eine Abbauentscheidung ordnen bekannte Abweichungen in die weitere Arbeit ein. Häufige Änderungen, komplexe Hotspots oder gemeinsame Commits geben Prüfhinweise, belegen aber keine Ursache. Die Untersuchung konkreter Änderungen vertieft Software Analytics.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Wie viele Direktzugriffe zeigt das Visual in Woche 4 ohne Prüfung?
Lösung mit Begründung ansehen
5 Direktzugriffe, davon 3 neue unbemerkte (illustrativ).
AnwendenAuf eine neue Lage übertragen
Ein Pull Request fügt einen weiteren Direktzugriff des Versandmoduls hinzu. Wie hilft die Prüfung?
Lösung mit Begründung ansehen
Sie markiert ihn als neue Abweichung über der Baseline von 2. Der Code geht dann über den Bestellvertrag.
BewertenEine Alternative abwägen
Das Team will erst alle Altzugriffe beheben, bevor es die Prüfung einschaltet. Was spricht dafür, was dagegen, was empfiehlst du?
Lösung mit Begründung ansehen
Vorteil: ein sauberer Zustand ohne Ausnahmen. Nachteil: Bis dahin wachsen neue Zugriffe unbemerkt. Empfehlung: Prüfung sofort mit Baseline einschalten und Altzugriffe mit Besitzer und Termin abbauen.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- ArchUnit – User Guide (öffnet in neuem Tab)Zeigt ausführbare Regeln für Abhängigkeiten, Schichten und Architekturkonformität.
- Governing data products using fitness functions (öffnet in neuem Tab)Zeigt überprüfbare Architekturziele und automatisierte Fitness Functions am Beispiel von Datenprodukten.
- SEI – Architecture Reconstruction (öffnet in neuem Tab)Beschreibt die Rekonstruktion bestehender Architektur zur Analyse von Abweichungen.
- Markus Harrer · Software Analytics (öffnet in neuem Tab)Softwaredaten als Grundlage für Fragen, Untersuchungen und fundierte Verbesserungen.