Design the in-process object model and core APIs for the ordering engine behind a meal-ordering app (think of the screen where a diner browses one eatery's menu, fills a cart, pays, and then watches the order progress). This is the domain core only — the classes that a mobile client and a kitchen console both call into.

Operating context. A diner opens a single restaurant, adds menu items (some with required or optional modifier groups, e.g. size, extra cheese) to a cart, applies at most one promotion, and checks out. Checkout picks a payment method, charges it, and turns the cart into an order. From there the order walks a fixed lifecycle — placed, then accepted or rejected by the restaurant, then preparing, ready, out-for-delivery, delivered — with cancellation allowed only in the early states. A restaurant can be closed or can flag individual items as sold-out, and the model must refuse to sell what isn't available. Everything runs in one process; there is no network hop between these objects.

Out of scope. Persistence and ORM mapping (assume an in-memory repository for v1), the REST/gRPC surface and serialization, real payment-gateway credentials and PCI handling, courier dispatch and live GPS tracking, and menu-authoring / restaurant-onboarding tools.

What to produce. The class hierarchy (entities, value objects, services), the public API each class exposes, and the two state machines that matter: the order lifecycle and the availability rules that gate what can enter a cart. Be explicit about how the order lifecycle rejects illegal transitions, how pricing composes line totals, taxes, and a promotion into a final amount, how payment is abstracted so a new method (wallet, cash-on-delivery) drops in without touching checkout, and how a new promotion type or a new lifecycle stage is added without editing existing classes.