Oyun Kitabı
Bilet Yaşam Döngüsü: Satıldı, Kullanıldı, İptal (Bilet Yasam Dongusu Sold Used Canceled)
Bilet Yaşam Döngüsü: Satıldı, Kullanıldı, İptal — lojistik operasyonlarında üretim dersi.
Partner Feribot Rezervasyon Masası
Bolum 2 / 8
Feribot partner kapasitesini bilet yaşam döngüsü ve indirim workflow'u ile yönetme serisi.
Bilet Yaşam Döngüsü: Satıldı, Kullanıldı, İptal
Durum geçişi olmayan bilet envanteri yalandır. Tickets need explicit transitions and active flags; reports must count sold/used/canceled/not-matched separately.
Sold → Used
Sold → Canceled
Active/Inactive flags
Durum geçişi olmayan bilet envanteri yalandır.
Kavramlar ilk geçtiği yerde
📦 Partner Capacity
Feribot partnerinin sunduğu sefer/kapasite gerçeği; düz CRUD satırı değildir.
📦 Ticket Lifecycle
Biletin sold → used → canceled gibi durum geçişleri.
📦 Discount Workflow
Hesapla / onayla / geri al adımları olan iş akışı.
📦 Booking Desk
Partner operasyonunun bilet ve araç bağlamını yönettiği yüzey.
Bu kavramları ayırt edemeyen ekip, UI ile entegrasyon sınırını karıştırır.
Problemin şekli
Tickets need explicit transitions and active flags; reports must count sold/used/canceled/not-matched separately.
Sold → Used
Sold → Canceled
Active/Inactive flags
Çalışan ayrım
Durum geçişi olmayan bilet envanteri yalandır.
Sold → Used
Sold → Canceled
Active/Inactive flags
↓
explicit contract
Üretimde kırılan yer
Sözleşme veya yarıçap/kimlik/deploy varsayımları gizlendiğinde incident büyür. Görünür sözleşme, görünür geri alma.
Bu bölümde en çok karışan eşleştirmeler
❌ Her şey tek uygulamada daha güvenli
✓ Sınırlar net değilse tek uygulama daha kırılgandır
❌ Konfigürasyon kodda hardcoded kalsın
✓ Yarıçap, remote URL ve expose path operasyonel kontratlardır
❌ Vendor/API gerçeği UI state'tir
✓ Vendor feed kanıt, ops state karardır
Kendi sisteminizi denetleme listesi
- Bu yüzeyin sahiplik sınırını bir cümleyle yazın.
- Hangi kontrat değişirse kim deploy eder?
- Timeout veya vendor gecikmesinde UI ne gösterir?
- Standalone ve gömülü senaryoları ayrı test ediyor musunuz?
- Deny-list: içerikte firma/vendor domain sızıntısı var mı?
Bu bölümden aklında kalması gerekenler
- Sözleşme görünür olmalıdır: expose path, yarıçap, ticket durumu veya remote URL.
- UI ile dış sistem arasındaki boşluk tasarım kararıdır, bug değil.
- Bağımsız deploy, bağımsız geri alma demektir.
Gizlediğiniz sınır, üretimde sizi bulur.
SSS
Sık sorulan sorular
Partner Capacity nedir?
Feribot partnerinin sunduğu sefer/kapasite gerçeği; düz CRUD satırı değildir.
Ticket Lifecycle nedir?
Biletin sold → used → canceled gibi durum geçişleri.
"Her şey tek uygulamada daha güvenli" doğru mu?
Sınırlar net değilse tek uygulama daha kırılgandır
Bu bölüm neyi sabitler?
Durum geçişi olmayan bilet envanteri yalandır. Durum geçişi olmayan bilet envanteri yalandır. Tickets need explicit transitions and active flags; reports must count sold/used/canceled/not-matched separately.
Ogrenilen Muhendislik Prensipleri
- Sahiplik ve yayın sınırı, domain model kadar gerçektir.
- Dış sistem kanıt üretir; operasyonel durum sizde karara bağlanır.
- Kontratı semver gibi yönetin; iç detayı serbest bırakın.
Okumaya devam et
Okumaya devam et
Seride sonraki yazi
Şirket, Araç, Sürücü: Booking Bağlamı
Şirket, Araç, Sürücü: Booking Bağlamı — lojistik operasyonlarında üretim dersi.
Seride sonraki yazi
Partner Kapasitesi Bir CRUD (Create, Read, Update, Delete) Tablosu Değildir
Feribot partner kapasitesini satır ekle-sil gibi modellemek, bilet yaşam döngüsünü ve onay akışlarını yok sayar.
Ayni seriden
İndirim Onayı Bir İş Akışıdır (Workflow)
İndirim Onayı Bir İş Akışıdır (Workflow) — lojistik operasyonlarında üretim dersi.