Partner-Kapazität ist keine CRUD (Create, Read, Update, Delete)-Tabelle (Partner Kapazitaet Ist Keine Crud Tabelle)

Kapazität ist ein Voyage-Vertrag, kein Regal

Partner-Kapazität lebt mit Firmen, Fahrzeugen, Fahrern und Rabattregeln. Als generisches CRUD endet es in Cancel-/Usage-Patches.

Partner voyage capacity
   ├─ tickets (lifecycle)
   ├─ companies / vehicles / drivers
   └─ discounts (workflow)
          ↓
   Booking desk decisions

Diese Serie baut einen Fähr-Booking-Desk mit Domänen- und MFE-Grenzen.

Begriffe, dort definiert, wo sie zuerst auftauchen

📦 Partner Capacity
Verkauf-/Nutz-Kapazität einer Partner-Voyage.

📦 Booking Desk
Ops-Oberfläche für Tickets und Kontext.

📦 Lifecycle Field
Zustandsfeld mit Übergangsregeln — kein plain CRUD.

📦 Partner Contract Leak
Vertragsdetails in UI/Reports.

Kapazität als Tabellenzeile wird bei Cancel und Billing teuer.

Wo CRUD bricht

Ein sold Ticket kann vor use canceled werden — kein Stock-Decrement.

Kontext ist Pflicht

Ohne Firma-Fahrzeug-Fahrer ist ein Ticket sinnlos.

Ticket → requires context graph

MFE-Grenze

Booking-Remote embedded in Shell und standalone.

Die am häufigsten verwechselten Zuordnungen

❌ Ticket = Produktbestand
✓ Ticket = Kapazitätsrecht mit Lifecycle

❌ Rabatt = Preisfeld
✓ Rabatt = genehmigter Workflow

❌ Partner-Interna überall
✓ Contract Leakage in Reports blocken

Checkliste zur Prüfung des eigenen Systems

1. Haben Sie ein Ticket-Übergangsdiagramm?
2. Welche Side Effects hat Cancel?
3. Wer muss Rabatte genehmigen?
4. Wer nutzt die Standalone-URL?
5. Partner-Sprache in Report-Feldern?

Was aus diesem Teil bleiben sollte

1. Partner-Kapazität ist lifecycle-förmig.
2. Kontextgraph gehört zum Ticket.
3. MFE-Grenzen schützen Desk-Tempo.

Wer Kapazität als CRUD sieht, sieht Cancel als DELETE.