Der vollständige Zustandsraum
Acht Zustände bilden den Lebenszyklus eines Mietverhältnisses ab. Der Hauptzustand laufende_vermietung ist die Zeit, in der das Mietverhältnis produktiv läuft — oft Jahre. Alle anderen Zustände sind Übergangsphasen mit klar definierten Ein- und Ausgängen:
stateDiagram-v2
direction LR
[*] --> anbahnung
anbahnung --> mietvertrag_aktiv : qes_abgeschlossen
mietvertrag_aktiv --> laufende_vermietung : einzug_durchgefuehrt
laufende_vermietung --> gekuendigt : kuendigung_zugestellt
gekuendigt --> uebergabe_durchgefuehrt : uebergabe_abgeschlossen
uebergabe_durchgefuehrt --> kaution_rueckzahlung_aktiv : kaution_starten
kaution_rueckzahlung_aktiv --> mietvertrag_abgeschlossen : kaution_abgeschlossen
mietvertrag_abgeschlossen --> abgeschlossen : finalisieren
abgeschlossen --> [*]Migration M204 legt die State-Map an, M206 die Sub-Workflow-Bindings, M207 die Lifecycle-Event-Konfiguration, M208 die Permission-Matrix, M214 die Zeitachsen-Materialized-View, M217 die Konflikt-Guards für parallele Subs und M232 die Erweiterung um den Zustand kaution_rueckzahlung_aktiv.
Sub-Workflow-Bindings
Die wichtigste Eigenheit des Master-Workflows ist die datengetriebene Steuerung der Sub-Workflows. In Migration M206 ist eine Bindings-Tabelle hinterlegt mit der Form (parent_state, trigger_event, sub_workflow_type, condition). Die wichtigsten Bindings:
stateDiagram-v2
direction LR
state Master {
anbahnung
laufende_vermietung
gekuendigt
uebergabe_durchgefuehrt
}
state Subs {
vertragsabschluss
mieterhoehung
mietminderung
modernisierung
anfrage_general
schaden
kuendigung_573c
wohnungsuebergabe
kaution_rueckzahlung
}
anbahnung --> vertragsabschluss : auto-start
laufende_vermietung --> mieterhoehung : auf Verwalter-Trigger
laufende_vermietung --> mietminderung : auf Mieter-Antrag
laufende_vermietung --> modernisierung : auf Eigentümer-Trigger
laufende_vermietung --> anfrage_general : auf Anfrage-Eingang
laufende_vermietung --> schaden : auf Schaden-Eingang
laufende_vermietung --> kuendigung_573c : auf Kündigungs-Eingang
gekuendigt --> wohnungsuebergabe : auf Termin-Setzung
uebergabe_durchgefuehrt --> kaution_rueckzahlung : auto-startDie wichtigsten Sub-Workflows im Detail:
vertragsabschluss— Selbstauskunft, Bonitätsprüfung, QES, Wohnungsgeberbestätigung. Startet automatisch im Master-Zustandanbahnung.mieterhoehung— Vergleichsmieten-Erhebung, Mieter-Anschreiben, Frist-Tracking, optional Räumungsklage. Auf Verwalter-Trigger startbar.mietminderung— Mängel-Erfassung, Minderungs-Berechnung, Mieter-Verhandlung. Auf Mieter-Antrag startbar.modernisierung_einspruch— Modernisierungs-Ankündigung nach § 555c BGB, Mieter-Einspruchsphase, Härtefall-Prüfung, Bauphase.anfrage_general— Mieter-Anfragen aus Portal/E-Mail/WhatsApp (siehe Anfragen-Ticket-Workflow).schaden— Versicherungsschäden mit Gutachter-Termin und Auszahlung.kuendigung_573c— Mieter- oder Verwalter-Kündigung mit Frist-Tracking nach § 573c BGB.wohnungsuebergabe— Übergabe mit Doppel-Signatur und Mängel-Erfassung (siehe Wohnungsübergabe-Workflow).kaution_rueckzahlung— Kaution-Abrechnung mit Schadensabzug und Auszahlung an Treuhandkonto-Inhaber.
Weitere Sub-Workflow-Typen sind über Migrationen ergänzbar, ohne dass der Master-Workflow angepasst werden muss — die Bindings-Tabelle ist offen.
Beispiel: Mietverhältnis Frau S., Lindenstraße 12, App. 4B (2020–2026)
Frau S. zieht 2020 in die Wohnung ein, zieht 2026 aus. In dieser Zeit laufen mehrere Sub-Workflows. So sieht der Lebenszyklus aus der Master-Perspektive aus:
sequenceDiagram
autonumber
participant M as Master vermietung
participant V as Sub vertragsabschluss
participant E as Sub mieterhoehung (2023)
participant Mi as Sub mietminderung (2024)
participant Mod as Sub modernisierung (2025)
participant K as Sub kuendigung_573c (2026)
participant U as Sub wohnungsuebergabe (2026)
participant Ka as Sub kaution_rueckzahlung (2026)
Note over M: 2020-03 — Master startet in "anbahnung"
M->>V: child_started:vertragsabschluss
V-->>M: child_completed:vertragsabschluss (qes_ok)
M->>M: Transition zu "mietvertrag_aktiv"
M->>M: Einzug am 1. April 2020 → "laufende_vermietung"
Note over M: 2023-07 — Verwalter startet Mieterhöhung
M->>E: child_started:mieterhoehung
E-->>M: child_completed:mieterhoehung (zustimmung)
Note over M: 2024-02 — Heizungsausfall, Mieterin meldet
M->>Mi: child_started:mietminderung
Mi-->>M: child_completed:mietminderung (verhandelt)
Note over M: 2025-05 — Eigentümer plant Modernisierung
M->>Mod: child_started:modernisierung_einspruch
Mod-->>M: child_completed:modernisierung_einspruch (umgesetzt)
Note over M: 2026-01 — Frau S. kündigt
M->>K: child_started:kuendigung_573c
K-->>M: child_completed:kuendigung_573c (frist_abgelaufen)
M->>M: Transition zu "gekuendigt"
M->>U: child_started:wohnungsuebergabe
U-->>M: child_completed:wohnungsuebergabe (abgeschlossen)
M->>M: Transition zu "uebergabe_durchgefuehrt"
M->>Ka: child_started:kaution_rueckzahlung
Ka-->>M: child_completed:kaution_rueckzahlung (auszahlung_ok)
M->>M: Finale Transition zu "abgeschlossen"Sechs Jahre Mietverhältnis, sieben Sub-Workflows, eine durchgängige Audit-Spur. Der Verwalter sieht im Master-Cockpit die komplette Zeitachse mit allen Subs als horizontale Balken — ohne dass er Excel-Tabellen oder Aktenordner konsultieren muss.
Lifecycle-Events im Detail
Die drei Lifecycle-Events sind das technische Rückgrat der Master-Sub-Kommunikation. Jedes Event trägt eine strukturierte Payload und wird im Audit-Trail beider Workflows gespeichert:
child_started:<typ>— Master speichert die Sub-Referenz in einer Materialized View, der Master-Status-Badge zeigt „Sub läuft“. Bei parallelen Subs des gleichen Typs greift der Konflikt-Guard und blockiert den zweiten Start.child_completed:<typ>— Sub hat Terminal-Zustand erreicht (z. B.erfolgreichoderwidersprochen). Master prüft, ob aus diesem Status eine Master-Transition folgt. Beichild_completed:wohnungsuebergabe mit status=abgeschlossentriggert Master die Transition nachuebergabe_durchgefuehrt.child_cancelled:<typ>— Sub wurde manuell abgebrochen. Master bleibt im aktuellen Zustand, schreibt Audit-Eintrag mit Begründung. Der Verwalter kann manuell entscheiden, ob ein Folge-Sub erforderlich ist.
Die Events sind asynchron: Ein Master-Workflow kann mehrere Events in kurzer Zeit empfangen und sequenziell verarbeiten. Die Engine garantiert Reihenfolge pro Master-Workflow-ID — keine Race-Conditions zwischen parallelen Subs.
Technisch erzwungene Compliance
Der Master-Workflow erzwingt drei Compliance-Eigenschaften, die in der Praxis oft schwierig sind: Vollständigkeit (kein Mietverhältnis verschwindet aus der Verwaltung, jedes hat einen aktuellen Zustand), Nachvollziehbarkeit (jeder Vorgang ist im Audit-Trail mit Person, Zeitpunkt und Begründung dokumentiert) und Anschlussfähigkeit (beim Eigentümerwechsel oder Verwalter-Wechsel ist die komplette Historie übergebbar — als PDF-Export oder als API-Datenstrom).
Die Sub-Workflow-Bindings sind nicht in Code, sondern in der Datenbank versioniert. Das bedeutet: Eine Anpassung an neue rechtliche Anforderungen (etwa neue WEG-Reform 2027) erfolgt per Migration, nicht per Deployment. Das schützt vor Drift zwischen Verwaltungspraxis und Software, weil die Sub-Workflow-Konfiguration so dokumentiert ist wie der Code, der sie ausführt.