ADR-018: ServiceLeg Creation Ownership

Status: 🟡 Requires architect approval Triggered by: Level 2 Audit — ServiceLeg Lifecycle & BoardingEvent (Finding F7)

Context

The TripPublished event signals that a TourDeparture is ready for Operations. The domain model states ServiceLegs belong to Operations, but the Backoffice itinerary defines their structure (leg types, stop sequence, scheduled times). Two options exist:

• Option A — Backoffice creates ServiceLegs as part of the publishing flow, writing directly to the Operations schema.
• Option B — Operations consumes TripPublished and creates its own ServiceLegs from the event payload.

Decision

Option B — Operations creates its own ServiceLegs.

The TripPublished event payload includes the full itinerary structure (stops, times, leg types, boarding points). Operations' event handler creates ServiceLegs, RouteWaypoints, and stub LegAssignments. This preserves bounded context ownership: Operations owns its aggregate root.

Why not Option A?

Option A requires Backoffice to write directly into the Operations schema, violating bounded context boundaries. It creates a deployment coupling (Backoffice must know Operations' schema version) and makes the creation flow harder to test, version, and evolve independently.

Consequences

• TripPublished event payload must include the full itinerary structure (stops, times, leg types, boarding points)
• Operations must handle idempotent re-creation if the dispatcher re-publishes a modified departure (upsert by tour_departure_id + sequence_order)
• No cross-schema writes from Backoffice into Operations
• service_legs.tour_departure_id stores the Backoffice FK for dispatch board context
• The event payload schema must be formally specified in event-contracts-backoffice.md or equivalent protocol document (currently unspecified — flag as L3 drill-down dependency)