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

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

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

01使用者下單流程

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

開臺:服務員點選開臺,表示該桌臺已經被顧客使用

點餐:服務員操作點餐系統,代顧客點餐

下單:服務員點選下單,訂單資訊下發到廚房

結賬:使用者吃完後到前臺結賬,收銀員確認該用於已結賬

清檯:保潔員清理桌臺,之後服務員點選已經清檯,則下桌客人就可用餐了

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

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

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

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

02 領域驅動下的類圖

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

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

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

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

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

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

03 訂單與桌臺關係

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

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

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

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

然後基於桌臺的這些資訊,再將訂單邏輯考慮周到。

比如,非空閒的桌臺是不能再下單的。但如允許拼桌,則也可再下一單。

再如,使用者的就餐人數(在訂單裡反應)應小於該桌臺人數,如不符合就要有提醒。

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

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

好了,這就是今天的內容。總之學好UML,就能考慮周全,避免返工!希望本文能幫到你,全文完!

TIPS:

有些人認為設計就是看起來長什麼樣。但是如果你深入挖掘就會發現,設計更關乎如何運作。——史蒂夫·喬布斯。

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

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

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

題圖來自Unsplash,基於CC0協議

頂部