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 |
|---|---|
| Neu vorgeschlagen, noch nicht entschieden oder begonnen |
| In der Designphase, noch nicht implementiert |
| Aktuell in Entwicklung |
| Produktiv im Einsatz |
| Veraltet, soll nicht mehr genutzt werden — aber noch aktiv |
| 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 statusAusgabe:
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 deprecatedJSON-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 |
|
Implementierung beginnt |
|
Produktiv-Deployment |
|
Ablösung beschlossen (ADR erstellt) |
|
System abgeschaltet |
|
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