Playbook
Companies, Vehicles, Drivers as Booking Context (Companies Vehicles Drivers As Booking Context)
Companies, Vehicles, Drivers as Booking Context — a production lesson from logistics operations platforms.
Partner Ferry Booking Desk
Part 3 of 8
A series on managing ferry partner capacity through ticket lifecycles and discount workflows.
Companies, Vehicles, Drivers as Booking Context
Active switches on companies/vehicles/drivers gate whether tickets can be sold or used.
Company — Vehicle — Driver — Ticket
Bağlam kapalıysa bilet satışı da kapalıdır.
Concepts, defined where they first appear
📦 Partner Capacity
Ferry partner voyage/capacity truth — not a flat CRUD row.
📦 Ticket Lifecycle
Transitions such as sold → used → canceled.
📦 Discount Workflow
Calculate / approve / revert steps with authority gates.
📦 Booking Desk
Surface where partner ops manage tickets and vehicle context.
Teams that blur these concepts confuse UI state with integration truth.
Shape of the problem
Active switches on companies/vehicles/drivers gate whether tickets can be sold or used.
Company — Vehicle — Driver — Ticket
The split that works
Bağlam kapalıysa bilet satışı da kapalıdır.
Company — Vehicle — Driver — Ticket
↓
explicit contract
Where production breaks
Incidents grow when radius, identity, or deploy assumptions stay implicit. Make the contract visible and reversible.
The mappings that get confused most often
❌ One app is always safer
✓ Without clear boundaries, one app is more fragile
❌ Keep config hardcoded
✓ Radius, remote URLs, and expose paths are operational contracts
❌ Vendor/API truth is UI state
✓ Vendor feed is evidence; ops state is a decision
A checklist for auditing your own system
- Write the ownership boundary for this surface in one sentence.
- If this contract changes, who deploys?
- On timeout or vendor delay, what does the UI show?
- Do you test embedded and standalone paths separately?
- Deny-list check: any vendor/domain leakage in copy?
What to take away from this part
- Contracts must be visible: expose paths, radius, ticket state, or remote URLs.
- The gap between UI and external systems is a design choice, not a bug.
- Independent deploy means independent rollback.
The boundary you hide will find you in production.
FAQ
Frequently asked questions
What is Partner Capacity?
Ferry partner voyage/capacity truth — not a flat CRUD row.
What is Ticket Lifecycle?
Transitions such as sold → used → canceled.
Is it true that "One app is always safer"?
Without clear boundaries, one app is more fragile
What does this part lock in?
Bağlam kapalıysa bilet satışı da kapalıdır. Active switches on companies/vehicles/drivers gate whether tickets can be sold or used.
Engineering Principles Learned
- Ownership and release boundaries are as real as the domain model.
- External systems produce evidence; operational state is decided by you.
- Version the contract; keep internals free to move.
Continue reading
Continue reading
Next in series
Discount Approval as a Workflow
Discount Approval as a Workflow — a production lesson from logistics operations platforms.
Next in series
Ticket Lifecycle: Sold, Used, Canceled
Ticket Lifecycle: Sold, Used, Canceled — a production lesson from logistics operations platforms.
Same series
Partner Capacity Is Not a CRUD (Create, Read, Update, Delete) Table
Modeling ferry partner capacity as insert-delete rows ignores ticket lifecycles and approval flows.