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.

類型 流程圖標準 Sugiyama layered DAG + orthogonal routing引擎 schematex-flowchart更新時間 2026/9/24

需求

“Create an event storming diagram for a hotel booking: Request booking causes Booking requested; an availability policy causes Room held; capture deposit causes Deposit captured; confirm reservation causes Reservation confirmed; then a confirmation policy sends the confirmation. Color commands blue, events orange, and policies green.”

接著試試Add a Room hold expired event after Room held.Add a Reservation cancelled command and event.

這張圖裡有什麼

看懂背後的決策。

01Set hold rule

Define how long a room hold lasts.

02Separate payment

Model deposit capture as its own action.

03Confirm facts

Make Reservation confirmed the final business event.

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

瀏覽所有流程圖範本 →

常見問題

Why is Room held an event?

It records that availability has been temporarily reserved.

What happens if payment fails?

Add a failed-payment event and a policy for releasing or retaining the hold.

Why separate confirmation from payment?

A reservation rule may require more than a successful deposit before confirmation.