Restaurant Domain

The Restaurant domain covers all in-restaurant and customer-facing operations. It is the largest of the three domains, containing six bounded contexts and two external system integrations.

Domain Definition

The Restaurant domain includes its contexts via RIDDL's include mechanism, keeping each context in its own file for maintainability:

domain Restaurant is {

  author OssumInc is {
    name is "Ossum Inc."
    email is "info@ossuminc.com"
  } with {
    briefly "Author"
    described by "Ossum Inc."
  }

  include "FrontOfHouseContext.riddl"
  include "KitchenContext.riddl"
  include "BarContext.riddl"
  include "OnlineOrderingContext.riddl"
  include "DeliveryContext.riddl"
  include "LoyaltyContext.riddl"
  include "external-contexts.riddl"

} with {
  briefly "Restaurant operations domain"
  described by {
    | Covers all in-restaurant and customer-facing operations
    | including front-of-house, kitchen, bar, online ordering,
    | delivery, and loyalty program.
  }
}

Bounded Contexts

Context	Purpose	Entities	Details
Front of House	Reservations, table orders, billing	Reservation, TableOrder	Projector: ReservationBoard
Kitchen	Ticket queue, station assignment, QC	KitchenTicket	Projector: KitchenDisplay
Bar	Drink orders with push notifications	DrinkOrder	Solves melting-ice problem
Online Ordering	Menu browsing, cart, checkout	OnlineOrder	Decoupled from delivery
Delivery	Driver dispatch, GPS tracking	DeliveryOrder	Offline resilient
Loyalty	Points accrual and redemption	LoyaltyAccount	Incremental rollout

Plus two external contexts: PaymentGateway and NotificationService.

Cross-Context Communication

The contexts communicate through adaptors, not direct calls. This diagram shows the message flow:

FrontOfHouse ──ToKitchen──► Kitchen ◄──FromOnlineOrdering── OnlineOrdering
     │                                                           │
     ├──ToBar──────────► Bar                                     ├──ToKitchen──► Kitchen
     │                                                           │
     ├──ToLoyalty──────► Loyalty ◄──FromPayment (dine-in)        ├──ToDelivery─► Delivery
     │                          ◄──FromOnlinePayment (online)    │
     └─────────────────────────────────────────────────────      └──ToLoyalty──► Loyalty

Key patterns:

• Outbound adaptors (to) route messages from one context to another — e.g., FrontOfHouse.ToKitchen sends food items to the Kitchen context
• Inbound adaptors (from) receive and transform messages from another context — e.g., Kitchen.FromFrontOfHouse converts submitted orders into kitchen tickets
• Multiple sources — Kitchen receives tickets from both FrontOfHouse (dine-in) and OnlineOrdering (online), each through its own adaptor

Challenges Addressed

Based on the personnel interviews:

Persona	Challenge	Context Solution
Host	Unresponsive reservations	FrontOfHouse with event sourcing
Server	Terminal contention	Async event-driven ordering
Chef	Lost orders on crash	Kitchen with persistent tickets
Cook	Illegible handwritten tickets	KitchenDisplay projector
Bartender	Drinks sit and ice melts	Bar push notifications
Delivery Driver	App drops connectivity	Delivery offline resilience
Online Customer	Website unreliable	OnlineOrdering isolation

Source

restaurant/domain.riddl