1.5 KiB
1.5 KiB
1. Deal Status Machine
Status
- Status: Proposed
- Date: 2026-03-06
- Author: openclaw
Problem
Die Geschäftslogik für Anfrage->Angebot->Verhandlung->Deal ist komplex; ohne dokumentierte Zustandsregeln entstehen Inkonsistenzen.
Lösung
Wir führen eine Statusmaschine ein, die alle erlaubten Übergänge und Guard Conditions definiert. Die Maschine umfasst folgende Zustände:
REQUESTEDOFFEREDNEGOTIATINGACCEPTEDREJECTEDEXPIRED
Zustandsübergänge
| Von | Nach | Guard Condition |
|---|---|---|
| REQUESTED | OFFERED | Angebot muss von einem Benutzer erstellt werden |
| OFFERED | NEGOTIATING | Verhandlung muss vom Empfänger gestartet werden |
| NEGOTIATING | ACCEPTED | Akzeptanz durch den Empfänger |
| NEGOTIATING | REJECTED | Ablehnung durch den Empfänger |
| NEGOTIATING | EXPIRED | Ablauf der Verhandlungszeit |
| OFFERED | REJECTED | Ablehnung durch den Empfänger |
| OFFERED | EXPIRED | Ablauf der Angebotszeit |
| REQUESTED | REJECTED | Ablehnung durch den Empfänger |
| ACCEPTED | EXPIRED | Ablauf der Deal-Zeit |
Fehlerszenarien
- Race Conditions: Mehrere Benutzer versuchen gleichzeitig einen Status zu ändern. Lösung: Transaktionen mit Versionierung.
- Doppelte Annahmen: Ein Benutzer akzeptiert ein Angebot, während ein anderer es bereits abgelehnt hat. Lösung: Zustandsprüfungen vor jeder Änderung.
Referenz
- Backend Validierungen und Tests werden direkt aus dieser ADR abgeleitet.