We will use this case study in the Domain-Driven Design (DDD) Master course to specify and implement a (somewhat) large software system, as a prototye.
This description is intended as a starting point for your design and implementation process. It is not a living document – i.e. after the initial Event Storming workshop it will not be updated. It is likely incomplete and may contain inconsistencies. During the workshop and afterward, we can jointly decide to deviate from this written version.
The description deliberately avoids making assumptions about a (backend) software architecture. While it is clear which clients exist, we will only refer to “the system” broadly. One of your tasks will be to determine appropriate subsystems or (in DDD terms) sub-domains and bounded contexts.
In this case study, you will work on a restaurant management system for the franchise chain Delicious. The brand plans to operate a large number of restaurants, all working with the same concept and workflows. Your software will be provided to all franchises.
Guests can use the Delicious App to search for a nearby restaurant, select it by clicking, and then book a table. They need to specify the day, time, and the number of persons. The app then either confirms the reservation and displays the table number or asks the customer to select another time or day, or change the number of persons. Guests can only reserve timeslots that are more than 2 hours in the future.
Alternatively, guests can walk in without a reservation. Each table displays its number and reservation state on a tablet attached to the table. This tablet can also display advertisements and other information. A reservation blocks the table for 90 minutes from other reservations. If there is a no-show (i.e., no food is ordered from the table), it is put back on the “free table” list 30 minutes after the original reserved time.
If guests sit down at a free table without a reservation, the table is marked as “taken” once the guests have ordered food (see below).
There are no waiters in the restaurant. The only way to order food at a table is via the Delicious App. Guests can each order (and pay for) their own meal, or one guest can order and pay for the entire group.
A guest first needs to scan the QR code displayed on the table’s tablet (denoting the table number). Then they select food items from a “menu catalog” and pay via credit card in the app. The app then displays an estimated waiting time, which is updated every minute. The backend system responsible for taking food orders tries to level out the waiting time on each table so that the entire group receives their food at (roughly) the same time.
When the food is ready, the guest’s Delicious App displays a notification and a QR code. The table’s tablet shows a blinking sign. The guest needs to fetch the food from the counter at the kitchen, where the cook scans the QR code and hands over the food.
Drinks are ordered without any digital processes at the bar from a human bartender. Drinks are paid for by cash or credit card at the bar’s cash register.
The bars are outsourced to a different company, which operates independently. Therefore, the entire aspect of “drinks” is out of scope for this restaurant management system.
For cost reasons, the cooks at Delicious restaurants do not need extensive training. The kitchen is organized into a number of “cooking stations.” Each station contains a stove, the necessary cooking utensils, and space for used pots, spoons, etc.
The used utensils are cleared regularly by a kitchen helper who puts them into the dishwasher and brings clean utensils to the cooking stations. This process does not require any digital support and is not modeled in the restaurant system.
Above each cooking station, there is a large monitor. When the cooking station receives a food order, the corresponding recipe is fetched and displayed in easy steps on the monitor. The cook working at the station fetches the ingredients from the adjacent storage/cooling room and starts cooking.
The cook has a dedicated Delicious Cooking App on their smartphone. At the beginning of the cooking process, the cook presses “start.” After each recipe step, the cook acknowledges the step in the app. (This information is used in the waiting time estimation for the guest’s app.) When handing over the food, the cook scans the guest’s QR code with their cooking app. This also signals that the cooking station is free to receive the next preparation order.
The cooks use their cooking app to check in or out of a cooking station (the stations are numbered). They check out for breaks and at the end of their shifts.
The ingredients in the storage/cooling room are managed outside the restaurant management system. The manager estimates the required amount of ingredients per day and ensures the storage is adequately stocked.
The manager also monitors the stock manually throughout the day. If, despite planning, stock for an ingredient gets low, the manager will manually deactivate the affected food items in the restaurant’s menu catalog using an Admin Client. This action marks the food item as “temporarily unavailable” in the guests’ Delicious App.
The Admin Client allows new cooks to be entered into the system so that they can log into the Cooking App. The duty rota for the cooks is managed manually outside the restaurant management system.
The Admin Client allows new food items and their recipes to be added using a dedicated editor. Food items can also be disabled or deleted.