HOSPITALITY

Hotel Booking Event Storming

This map models the core hotel reservation sequence from a booking request to a confirmed reservation. It makes the room-hold policy visible between availability checking and deposit capture, which is often where time limits and inventory rules need discussion. Commands ask for work, while the orange events establish the facts that other parts of the business can rely on. A real workshop should add failed payments, hold expiry, cancellation terms, room changes, and channel-manager updates. Keep each event specific enough that operations, sales, and engineering agree on what has happened and what data is needed next. Review the underlying definitions and totals before using this view to make an operational decision.

UPDATED 2026-09-25
EXAMPLEHotel Booking Event Storming
Make this diagram your own.

Open it in the AI editor with a prompt pre-filled — keep what works, change what doesn't.

CASE ANALYSIS

Scenario

Hotel reservation domain discovery

Key decisions

  • Set hold rule: Define how long a room hold lasts.
  • Separate payment: Model deposit capture as its own action.
  • Confirm facts: Make Reservation confirmed the final business event.

When to reuse this

Use for a reservation flow where availability and payment are distinct concerns.

FAQ

Frequently asked questions

Why is Room held an event?01
It records that availability has been temporarily reserved.
What happens if payment fails?02
Add a failed-payment event and a policy for releasing or retaining the hold.
Why separate confirmation from payment?03
A reservation rule may require more than a successful deposit before confirmation.
Open this example in the editor →

Tweak it with chat, export PNG/SVG, or fork it for your own use case.