**Use case #1: get available rooms**  
Data

- Room
-   
    - Type
    - Price
    - Description
    - Name
    - Pictures
- Check-in date
- Check-out date
   
 Actions

- get room description (type, picture, etc)
- get available room list
 **Use case #2: making a reservation**  
Data

- Guest
-   
    - First name
    - last name
- Payment information
-   
    - card number
    - expiration date
    - name on card
- check-in date
- check-out date
- room ID
      
 Actions

- room still available?
- reserve room for guest
- validate payment information
 **Use case #3: check-in process**  
Data

- Guest
-   
    - First name
    - Last name
- Payment information
-   
    - number
    - expiration date
    - name
- room
-   
    - number
    - type
         
 Actions

- Find reservation by guest name
- Find reservations by today's date
- realize reservation
 **Use case #4: check-out process**  
Data

- Guest
-   
    - GuestId
- Room
-   
    - RoomId
- Reservation
-   
    - ReservationId
    - Check out Date
             
**Homework:**  
Example problem domain: hotel management system.  
Marriott in Dallas.  A single hotel.  
Functionality to book a room.  
Search screen: check-in, check-out boxes.   _Frontend experience_  
Use case #1: availability by in/out dates.  What is the price?  Can be multiple types of rooms.  If multiple room types are available, show all and their prices.  don't look for complexity around pricing--just assume list price.   Use case #2: Making a reservation.  Guest information (first, last, etc), credit card information for securing reservation.  User clicks book now.  One guest, one room, one reservation.   _Hotel experience_  
Use case #3: check-in process.  Finding reservation based on guest's name (what type of room, how many nights).  Next, finding room to put guest in.   Use case #4: check-out process.  Simple for guest.  From hotel's perspective: this is last night of reservation, print up bill on that night.  Verify you've left the room.  Total charge (finalizing the charges)--did you trash room?  Did you eat minibar food?  Ultimately, charging card for appropriate total?   Edge cases to think about:

- Guest side: One room left, two people are trying to book it?  How to preserve consistency?  Overbooking is OK, but infinite overbooking is not allowed!
- Hotel side: No show.  Reservation made, but guest didn't show up. Probably a grace period.
 Objective: find service boundaries.  What are the services?  What data are they responsible for?  What parts of the UI are they responsible for?  What events do they publish?  What events to they subscribe to?  What do they do with the events?  How do they collaborate with each other to implement the flows discussed?   Hints:

- Be careful with naming services
- Consider using stand-in names for services (red, blue, green--colors), then name them at the end.
 
WHEN DOING DESIGN, DEFER NAMING AS LONG AS POSSIBLE!