Design the object model and core APIs for the booking core of a cinema-ticketing service (think the checkout flow behind a multiplex app) that a single operator runs in-process. A patron browses shows for a movie, picks specific seats off a screen's layout, is given a short-lived hold while they pay, and either confirms into a ticket or lets the hold lapse. The crux is the seat-hold lifecycle: two patrons must never end up owning the same seat for the same show, even when they tap at the same instant.

Operating context. One chain, a handful of theatres, each theatre with several screens, each screen showing many shows across a day. A screen has a fixed physical seat layout (rows and columns, with seat classes like recliner, premium, regular). A show is one movie on one screen at one start time and owns its own independent seat inventory. Many booking threads run concurrently against the same show. This is an in-process object model — no HTTP layer, no separate services, no network hops.

Out of scope. Persistence and any database schema, the real payment-gateway network integration (model it behind an interface you call), the movie/showtime catalog authoring UI, discount-coupon and loyalty engines, and notifications (email/SMS receipts). Assume other components own those.

What to produce. The class hierarchy (entities, value objects, and services), the public API each class exposes, and the explicit state machines for a seat-hold and for a booking. Be precise about: how a hold is placed atomically so concurrent booking threads cannot both grab the same seat; how a hold carries a TTL and expires so an abandoned cart self-heals; how price is computed from seat class plus show attributes through a pluggable pricing rule; how payment success or failure drives the booking state machine; and how cancellation returns seats to inventory. Draw the classes, their relationships, and the two state machines; we probe specifics at checkpoints.