Restaurant Food Ordering System

Phase 1: Requirements & Use Cases

Interviewer: "Design a restaurant food ordering system."

Candidate: "Sure. Let me confirm what we're building. I'm imagining an in-restaurant system — customers seat at tables, browse a menu, place orders with a waiter or kiosk, the kitchen receives and fulfills orders, and payment is processed at the end. Is this in-restaurant, or does it also include online/delivery?"

Interviewer: "In-restaurant only for now."

Candidate: "Perfect. I'll scope it to: table management, menu browsing, order creation and tracking, kitchen notification, and payment. No delivery, no loyalty programs, no inventory management for V1."

Interviewer: "What actors are involved?"

Candidate: "Four actors: a Customer (places order, requests bill), a Waiter (takes order, serves food, processes payment), a Chef/Kitchen (receives orders, marks dishes ready), and a Manager (configures menu, manages tables and staff). The system itself — the POS — is the orchestrator between them."

Interviewer: "Does a customer order directly, or only through a waiter?"

Candidate: "For V1, through a waiter — it simplifies the flow. I'd note that a self-service kiosk path could be added without changing the core order model; the kiosk would just be another actor creating the same Order objects."

WHY: Separating order creation (who creates it) from order representation (what it contains) means the waiter vs. kiosk distinction is a UI concern, not a domain model concern.

---

Core Use Cases:

1. Waiter seats a party at a table and opens a new order
2. Customer adds/removes items from the order
3. Waiter submits the order —…