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 = "Ossum Inc."
    email = "info@ossuminc.com"
  } with {
    briefly "Author"
    described as {
      |Ossum Inc., creators of RIDDL.
    }
  }

  // Each bounded context lives in its own file:
  //   include "FrontOfHouseContext.riddl"
  //   include "KitchenContext.riddl"   ... and four more

  // Cross-context connectors are DOMAIN-scoped in 2.0, and each end lands on
  // the context's OWN portlet -- reaching past a boundary to a contained
  // entity's inlet is an Error.
  context PaymentGateway is {
    outlet PaymentGatewayToFOHOut is type PaymentOutcome
    type PaymentOutcome is String(1,50)
  }
  context FrontOfHouse is {
    inlet PaymentGatewayToFOHIn is type PaymentGateway.PaymentOutcome
  }
  persistent connector PaymentGatewayToFOH is
    from outlet PaymentGateway.PaymentGatewayToFOHOut
    to inlet FrontOfHouse.PaymentGatewayToFOHIn

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

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