Partner Kapasitesi Bir CRUD (Create, Read, Update, Delete) Tablosu Değildir (Partner Kapasitesi Crud Tablosu Degildir)

Kapasite bir stok rafı değil, bir sefer sözleşmesidir

Partnerden gelen kapasite; şirket, araç, sürücü ve indirim kurallarıyla birlikte yaşar. Bunu generic CRUD ekranına indirgemek, iptal ve kullanım durumlarını sonradan yama yapmaya zorlar.

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

Bu seri, feribot rezervasyon masasını domain ve MFE sınırlarıyla kurar.

Kavramlar ilk geçtiği yerde

📦 Partner Capacity
Partner seferinin satılabilir/ kullanılmış kapasite gerçeği.

📦 Booking Desk
Bilet ve bağlamı yöneten operasyon yüzeyi.

📦 Lifecycle Field
CRUD'dan farklı olarak geçiş kuralları olan durum alanı.

📦 Partner Contract Leak
Rapor veya UI'da sözleşmeye özel kuralın sızması.

Kapasiteyi tablo satırı sanmak, iptal ve faturalamada pahalıya patlar.

CRUD'un kırıldığı yer

Sold bilet used olmadan canceled olabilir; stok düşümü gibi davranmaz.

Bağlam zorunlu

Şirket-araç-sürücü olmadan bilet anlamsızdır.

Ticket → requires context graph

MFE ile sınır

Booking remote hem shell'e gömülür hem standalone masada yaşar.

Bu bölümde en çok karışan eşleştirmeler

❌ Bilet = ürün stok satırı
✓ Bilet = yaşam döngülü kapasite hakkı

❌ İndirim = fiyat alanı
✓ İndirim = onaylı workflow

❌ Partner adı her yerde görünsün
✓ Raporlarda sözleşme sızıntısını engelleyin

Kendi sisteminizi denetleme listesi

1. Bilet durum geçiş diyagramınız var mı?
2. İptal hangi yan etkileri tetikliyor?
3. İndirim kim onaylamadan uygulanamıyor?
4. Standalone booking URL'i kim kullanıyor?
5. Rapor alanlarında partner-özel dil var mı?

Bu bölümden aklında kalması gerekenler

1. Partner kapasitesi yaşam döngülüdür.
2. Bağlam grafı (şirket/araç/sürücü) biletin parçasıdır.
3. MFE sınırları booking desk hızını korur.

Kapasiteyi CRUD sanan ekip, iptali bir DELETE sanır.