Teil 20: Element-Lifecycle — Status von proposed bis archived verfolgen

Dieser Post setzt den neunzehnten Teil fort. Architektur ist kein statisches Bild — Elemente werden vorgeschlagen, implementiert, deployed und irgendwann abgelöst. Das status-Feld in Bausteinsicht-Elementen macht diesen Lebenszyklus sichtbar. Status-Werte Status Bedeutung proposed Neu vorgeschlagen, noch nicht entschieden oder begonnen design In der Designphase, noch nicht implementiert implementation Aktuell in Entwicklung deployed Produktiv im Einsatz deprecated Veraltet, soll nicht mehr genutzt werden — aber noch aktiv archived Abgeschaltet, nur noch historisch im Modell Status im Modell setzen Das status-Feld gehört direkt ins Element: { "model": { "authservice": { "kind": "service", "title": "Auth Service", "technology": "Go", "status": "deployed" }, "paymentservice-v2": { "kind": "service", "title": "Payment Service v2", "technology": "Rust", "status": "implementation" }, "shop-monolith": { "kind": "system", "title": "Legacy Monolith", "status": "deprecated" }, "old-auth-session": { "kind": "service", "title": "Session-basierter Auth (alt)", "status": "archived" } } } Elemente ohne status-Feld gelten als unset. bausteinsicht status Alle Elemente mit ihrem Status: bausteinsicht status Ausgabe: Element Lifecycle Status ================================================== proposed (0): design (1): paymentservice-v2 [service ] "Payment Service v2" implementation (2): notificationservice [service ] "Notification Service" shop.checkout-v2 [component ] "Checkout v2" deployed (8): authservice [service ] "Auth Service" shop.api [service ] "Shop API" ... deprecated (1): shop-monolith [system ] "Legacy Monolith" archived (1): old-auth-session [service ] "Session-basierter Auth (alt)" unset (3): eventbus [queue ] "Event Bus" ... Gefiltert nach Status # Nur Elemente in Entwicklung bausteinsicht status --filter implementation # Nur veraltete Elemente bausteinsicht status --filter deprecated JSON-Ausgabe bausteinsicht status --format json { "summary": { "proposed": 0, "design": 1, "implementation": 2, "deployed": 8, "deprecated": 1, "archived": 1, "unset": 3 }, "elements": [ { "id": "authservice", "kind": "service", "title": "Auth Service", "status": "deployed" } ] } Das summary-Objekt gibt auf einen Blick die Verteilung wieder — nützlich als Dashboard-Metrik. Lifecycle im Kontext anderer Features Health Score bausteinsicht health wertet deprecated und archived Elemente in der Deprecation-Kategorie aus: Wenn ein deprecated-Element noch als Quelle oder Ziel in relationships erscheint, ist das ein Major-Finding (→ Teil 19). LSP / Editor Der Language Server zeigt den Status als CodeLens über jedem Element an (→ Teil 9): // service | status: deprecated | views: 2 "shop-monolith": { ... } Overlay Status-Werte lassen sich als Metriken-JSON exportieren und als Heatmap visualisieren (→ Teil 12): Deprecated-Elemente rot, deployed-Elemente grün. Sprint-basierter Workflow Zeitpunkt Status-Änderung Architekturentscheidung getroffen proposed → design Implementierung beginnt design → implementation Produktiv-Deployment implementation → deployed Ablösung beschlossen (ADR erstellt) deployed → deprecated System abgeschaltet deprecated → archived Status-Änderungen als Git-Commit dokumentieren: git commit -m "mark shop-monolith as deprecated (ADR-007)". Zusammen mit bausteinsicht changelog (→ Teil 7) entsteht so eine vollständige Architekturhistorie. Beispiel-Modell Das Beispiel für diesen Teil (alle Status-Werte von proposed bis archived) liegt unter teil_20.jsonc. So sieht das Ergebnis in draw.io aus (bausteinsicht sync): Das draw.io-File dafür findest du hier: teil_20.drawio Generierte PNG-Dateien via bausteinsicht export --image-format png: Generierte PlantUML-Diagramme via bausteinsicht export-diagram: Was als nächstes kommt Teil 21: As-Is / To-Be — Zielarchitektur direkt im Modell definieren und visualisieren Teil 22: find & show — Das Modell gezielt navigieren und Elemente erkunden Offizielle Dokumentation: User Manual · Tutorial auf doctoolchain.org