Design the application model for an automated parking garage. The garage has multiple levels and spot types. A vehicle requests entry, receives a compatible available spot, and later exits and pays. Gates and spot sensors may retry messages or report them out of order. Focus on objects, state transitions, interfaces, and invariants rather than a distributed deployment architecture. ### Constraints & Assumptions - One active parking session belongs to one vehicle and at most one spot. - A spot cannot be assigned to two active sessions. - A lost ticket or missing sensor event must have a defined recovery path. ### Clarifying Questions to Ask - Which vehicle and spot compatibility rules apply? - Is a reservation distinct from an occupied spot? - How is price computed, and when does payment become final? ```hint Model lifecycles explicitly A parking session can own the transition from entry authorization through assignment, occupancy, payment, and exit. ``` ### What a Strong Answer Covers - Cohesive entities, value objects, repositories, and service boundaries. - A valid session and spot state machine with idempotent commands. - Allocation policy separated from domain state and pricing policy separated from payment processing. - Concurrency, sensor reconciliation, and testable invariants. ### Follow-up Questions - How would reservations change allocation? - How would you handle a sensor that says a supposedly free spot is occupied? - Which operations must be atomic?