餐飲系統大拆解,理清訂單與桌臺之間的各種異常(3)

0 評論 4343 瀏覽 14 收藏 6 分鐘

導讀:這是餐飲系統大拆解第三篇。在第一篇中,我們用類圖拆解了員工信息;在第二篇中,我們用類圖拆解了套餐和桌臺信息;本篇將用類圖拆解訂單信息,從而將訂單的異??紤]全。同樣,本文也會講《圖解產品》一書中未講的知識,且閱讀本文需有該書的知識背景。

01用戶下單流程

用戶要點餐,他既可在網上自主下單,還可在現場由服務人員代為下單。為說明主要問題,我們只考慮由服務員下單這種情況,而其操作流程是:

  • 開臺:服務員點擊開臺,表示該桌臺已經被顧客使用
  • 點餐:服務員操作點餐系統,代顧客點餐
  • 下單:服務員點擊下單,訂單信息下發到廚房
  • 結賬:用戶吃完后到前臺結賬,收銀員確認該用于已結賬
  • 清臺:保潔員清理桌臺,之后服務員點擊已經清臺,則下桌客人就可用餐了

以上,就是服務員的操作流程。為了便于理解,該流程做了簡化。

那現在的問題是,如何將訂單的各種情況都考慮全?

這里有三個方法,分別是用例驅動、流程驅動和領域驅動。這三個方法都要運用,才能考慮全面。

在《圖解產品》一書中,用例驅動和流程驅動講的較多,但領域驅動講的少。本文就說說領域驅動這個方法。

02 領域驅動下的類圖

按照《圖解產品》一書的知識,你就可以梳理出訂單的類圖,梳理的方法有:看競品和進行用戶訪談,書中還講了具體的步驟。下圖就是是按此方法梳理出來的結果。

該圖表達了訂單是由訂單項(菜單的條目),支付信息與發票信息等組成的。如果你沒有看過書,我簡單解釋一下該圖。

在線條兩邊的數字,表示兩個類之間的數量關系,更準確地是對象間的數量關系)。如該系統支持一個訂單可以有多個支付,即用戶可同時使用購物卡和微信,來共同支付一個訂單。

為什么要梳理數量關系?因為這將影響原型設計。如一個訂單支持多個支付,那么在界面上,就要顯示購物卡抵扣的金額,再加上需要用微信支付的余額。

但上圖少了訂單與桌臺之間的數量關系,請你思考一下,兩者之間的數量關系是什么?

03 訂單與桌臺關系

按照《圖解產品》的思路分析,訂單與桌臺之間應為多對多的關系。即一個訂單可以關聯多個桌臺,且一個桌臺也可以關聯多個訂單。

一個訂單關聯多個桌臺的情況,如是公司的人一起吃飯,這就可能需要同時占用多個桌臺。一個桌臺有多個訂單的情況,當一個桌子只坐了一位客人,如允許第二個客人也在這個桌子上吃飯,也就是允許拼桌,則一個桌臺就有多個訂單。

而這個多對多的關系,我們也要在原型里體現出來。

但這還不夠,我們還應基于桌臺信息,再考慮TA對訂單的影響,即需要將“桌臺”這個類的信息列出,如桌臺的屬性有:位置、是否有包間費用,可坐幾人等;桌臺的狀態有:空閑、非空閑(已開臺、正清潔等)、維修等狀態。

然后基于桌臺的這些信息,再將訂單邏輯考慮周到。

  • 比如,非空閑的桌臺是不能再下單的。但如允許拼桌,則也可再下一單。
  • 再如,用戶的就餐人數(在訂單里反應)應小于該桌臺人數,如不符合就要有提醒。

最后,如該桌臺有包間費則應累計到訂單中。同時還需考慮一個訂單下,如果一個桌臺有包間費,另一個桌臺無包間費,又應如何計算費用。

總之,你需要考慮訂單與桌臺信息之間個各種交叉情況,即一對多,多對多等情況。如考慮不全,就可能導致研發重做,所以尤其要重視。

好了,這就是今天的內容??傊畬W好UML,就能考慮周全,避免返工!希望本文能幫到你,全文完!

TIPS:

有些人認為設計就是看起來長什么樣。但是如果你深入挖掘就會發現,設計更關乎如何運作?!返俜颉滩妓埂?/p>

產品經理則要用好UML,從而抽象出運作邏輯。

 

作者:擎蒼,《“圖解”產品:產品經理業務設計與UML建?!纷髡?,公眾號:圖解產品設計

本文由 @圖解產品設計 原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自Unsplash,基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!