Diese Fallstudie wird im DDD-Masterkurs verwendet, um ein (mittelgroßes) Softwaresystem als Prototyp zu spezifizieren und zu implementieren.
This is the case used in our Domain-Driven Design (DDD) Master course to specify and implement a (somewhat) large software system, as a prototype. It is also available as printable PDF.
This is the current version, with the changes made after the Event Storming (28.10.2026). Changed passages are highlighted in yellow (the PDF has the same text without highlighting):
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, except for the changes highlighted at the top. 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. Reservations start at a full or half hour. The restaurant has tables for two, four and eight persons, so a reservation is possible for up to eight persons; the app picks a free table that is just large enough for the group. 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. Every seat at a table has a QR code printed on it, with the table and seat number. A seat is occupied for at most 90 minutes, and this time cannot be extended. A reservation blocks the whole table for 90 minutes from the reserved time. For a walk-in guest, the 90 minutes start when they scan the QR code of a free seat. Walk-in guests can only sit down on a free seat at a table with no reservation starting within the next 90 minutes; when they scan the seat’s QR code, the app tells them whether they can.
If guests with a reservation have not ordered any food 30 minutes after the reserved time, the reservation lapses and the table is free again.
There are no waiters in the restaurant. The only way to order food is via the Delicious App. Every guest orders (and pays for) their own meal; there is no ordering for a whole group.
A guest first needs to scan the QR code on their seat. 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. If no cooking station is manned at that moment, the app does not accept the order. Nor does it accept an order when the guest’s remaining time at the seat is too short: the estimated waiting time plus at least 20 minutes for eating must fit into it.
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.
Cooks shouldn’t use their smartphone for hygiene reasons. Therefore, each cooking station has a Cooking Station Terminal: a large monitor above the stove and a big mechanical switch that the cook can operate even with greasy hands. The system assigns each food order to one of the manned cooking stations. 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. At the beginning of the cooking process, and after each recipe step, the cook presses the switch to move on to the next step. (This information is used in the waiting time estimation for the guest’s app.) After the last step, the monitor tells the cook in which compartment of the pickup station (see below) the food goes. Once the food is placed there, the cooking station is free to receive the next preparation order. A cook can reset a dish; the waiting time is updated.
There is no counter where cooks hand over food to the guests. Instead, between the kitchen and the guest area, there is a Pickup Station: a wall of numbered, heated compartments. Each compartment has two doors, one towards the kitchen and one towards the guests. The cook puts the finished food into the assigned compartment through the kitchen door and closes it again.
As soon as all dishes of an order are in their compartments, the Delicious App of the guest who placed the order displays a notification and a QR code. The guest goes to the pickup station and scans the QR code there. The guest doors of the matching compartments open, and the guest takes out the food. When both doors are closed again, the compartment can be used for the next dish.
If food is not collected within 15 minutes, or if a cook has finished a dish and no compartment is free, the guestroom manager gets a notification on the Admin Client. The guestroom manager then clears compartments by hand. The Admin Client shows who ordered which dish at which seat, so the guestroom manager can bring the food to the guest personally if need be.
The cooks check in or out of a cooking station (the stations are numbered). They check out for breaks and at the end of their shifts, but only after finishing the dish they are preparing. Orders that are already waiting are not affected by a check-out; they just take longer, and if no station is manned anymore, sorting that out is up to the guestroom manager. How exactly they check in and out is something we still need a solution for.
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.
Each recipe lists the ingredients it needs, and the system keeps track of what is in the storage/cooling room. As soon as a guest has ordered a dish, its ingredients are reserved in the stock, and when the cook prepares the dish, they are taken out. If the stock for an ingredient runs low, the system sends an alarm to the restaurant manager’s Admin Client. If the stock that is not yet reserved no longer covers a food item, the system automatically marks it as “temporarily unavailable” in the guests’ Delicious App.
For now, ordering supplies is done outside the restaurant management system. The restaurant manager estimates the required amount of ingredients per day and ensures the storage is adequately stocked. In the medium term, however, we want to automate this: each restaurant works with a list of trusted suppliers, and the system should order ingredients that run low from these suppliers by itself, in reasonable quantities. The delivery itself and putting the supplies away remain outside the system.
The restaurant manager can correct the stock by hand in the Admin Client, for instance when a delivery has been put away, or when an ingredient has gone bad and has to be thrown away.
Everything to do with our personnel is outside the scope of this system. Contracts, salaries, tax information and the duty rota are handled by external systems we already have, or manually. The restaurant management system does not need to know who our cooks are. For the system, a cook is just someone who checks in at a cooking station and checks out again, and it does not matter which person that is. Two more roles: the restaurant manager plans menu, stock and supplies; the guestroom manager clears uncollected food and takes over for a cook who cannot finish a dish.
The Admin Client allows new food items and their recipes, including the ingredients they need, to be added using a dedicated editor. Food items can also be disabled or deleted. Enabling and disabling food items is the restaurant manager’s job, and it changes over the year: some dishes are only offered while their ingredients are in season, and there can be regional reasons as well. Before Christmas, for instance, certain dishes are offered in larger quantities than during the rest of the year.