ADR-0021: First-Party-Statusmaschine für Anträge
- Status: accepted
- Datum: 2026-08-26
- Phase: P8
- Lastenheft: DASH-05
Kontext
Die Kette ist linear mit wenigen Verzweigungen: Entwurf, Einreichung, Prüfung, Genehmigung mit/ohne Auflagen, Ablehnung, Rückfrage. Lange Sagas oder BPMN-Modelle gibt es nicht.
Entscheidung
Explizite Transitionstabelle in FastAPI. Jeder erlaubte Wechsel schreibt genau ein procedure_events-Row. Unerlaubte Wechsel: HTTP 409. Erinnerungen an due_at über Celery. In-App-Inbox plus optionales SMTP.
Kette:
draft → submitted → in_review → approved | approved_with_conditions | rejected | clarification
clarification → submitted (Planer) oder in_review (Behörde). Terminal: approved, approved_with_conditions, rejected.
Begründung
Wenige Akteure, Audit ist Pflicht, Ops soll kein Java-BPM mitbringen. Celery ist schon da.
Verworfene Alternativen
| Alternative | Warum verworfen |
|---|---|
| Camunda / Flowable | Java-Ops, BPMN-Overhead für eine lineare Kette |
| Temporal | Keine Kompensations-Sagas; zusätzlicher Cluster |
| Ad-hoc Status-Strings ohne Tabelle | Uneinheitliche Clients, kein Audit-Vertrag |
Folgen
Neue Transition = Code + Test + Docs in derselben Änderung. Kein Workflow-Designer in v1.