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

01用戶下單流程

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

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

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

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

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

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

02 領域驅動下的類圖

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

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

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

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

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

03 訂單與桌臺關系

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

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

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

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

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

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

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

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

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

TIPS：

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

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

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

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

題圖來自Unsplash，基于CC0協議