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

01用戶下單流程

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

• 開臺(tái)：服務(wù)員點(diǎn)擊開臺(tái)，表示該桌臺(tái)已經(jīng)被顧客使用
• 點(diǎn)餐：服務(wù)員操作點(diǎn)餐系統(tǒng)，代顧客點(diǎn)餐
• 下單：服務(wù)員點(diǎn)擊下單，訂單信息下發(fā)到廚房
• 結(jié)賬：用戶吃完后到前臺(tái)結(jié)賬，收銀員確認(rèn)該用于已結(jié)賬
• 清臺(tái)：保潔員清理桌臺(tái)，之后服務(wù)員點(diǎn)擊已經(jīng)清臺(tái)，則下桌客人就可用餐了

以上，就是服務(wù)員的操作流程。為了便于理解，該流程做了簡(jiǎn)化。

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

這里有三個(gè)方法，分別是用例驅(qū)動(dòng)、流程驅(qū)動(dòng)和領(lǐng)域驅(qū)動(dòng)。這三個(gè)方法都要運(yùn)用，才能考慮全面。

在《圖解產(chǎn)品》一書中，用例驅(qū)動(dòng)和流程驅(qū)動(dòng)講的較多，但領(lǐng)域驅(qū)動(dòng)講的少。本文就說說領(lǐng)域驅(qū)動(dòng)這個(gè)方法。

02 領(lǐng)域驅(qū)動(dòng)下的類圖

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

該圖表達(dá)了訂單是由訂單項(xiàng)（菜單的條目），支付信息與發(fā)票信息等組成的。如果你沒有看過書，我簡(jiǎn)單解釋一下該圖。

在線條兩邊的數(shù)字，表示兩個(gè)類之間的數(shù)量關(guān)系，更準(zhǔn)確地是對(duì)象間的數(shù)量關(guān)系）。如該系統(tǒng)支持一個(gè)訂單可以有多個(gè)支付，即用戶可同時(shí)使用購(gòu)物卡和微信，來共同支付一個(gè)訂單。

為什么要梳理數(shù)量關(guān)系？因?yàn)檫@將影響原型設(shè)計(jì)。如一個(gè)訂單支持多個(gè)支付，那么在界面上，就要顯示購(gòu)物卡抵扣的金額，再加上需要用微信支付的余額。

但上圖少了訂單與桌臺(tái)之間的數(shù)量關(guān)系，請(qǐng)你思考一下，兩者之間的數(shù)量關(guān)系是什么？

03 訂單與桌臺(tái)關(guān)系

按照《圖解產(chǎn)品》的思路分析，訂單與桌臺(tái)之間應(yīng)為多對(duì)多的關(guān)系。即一個(gè)訂單可以關(guān)聯(lián)多個(gè)桌臺(tái)，且一個(gè)桌臺(tái)也可以關(guān)聯(lián)多個(gè)訂單。

一個(gè)訂單關(guān)聯(lián)多個(gè)桌臺(tái)的情況，如是公司的人一起吃飯，這就可能需要同時(shí)占用多個(gè)桌臺(tái)。一個(gè)桌臺(tái)有多個(gè)訂單的情況，當(dāng)一個(gè)桌子只坐了一位客人，如允許第二個(gè)客人也在這個(gè)桌子上吃飯，也就是允許拼桌，則一個(gè)桌臺(tái)就有多個(gè)訂單。

而這個(gè)多對(duì)多的關(guān)系，我們也要在原型里體現(xiàn)出來。

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

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

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

最后，如該桌臺(tái)有包間費(fèi)則應(yīng)累計(jì)到訂單中。同時(shí)還需考慮一個(gè)訂單下，如果一個(gè)桌臺(tái)有包間費(fèi)，另一個(gè)桌臺(tái)無包間費(fèi)，又應(yīng)如何計(jì)算費(fèi)用。

總之，你需要考慮訂單與桌臺(tái)信息之間個(gè)各種交叉情況，即一對(duì)多，多對(duì)多等情況。如考慮不全，就可能導(dǎo)致研發(fā)重做，所以尤其要重視。

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

TIPS：

有些人認(rèn)為設(shè)計(jì)就是看起來長(zhǎng)什么樣。但是如果你深入挖掘就會(huì)發(fā)現(xiàn)，設(shè)計(jì)更關(guān)乎如何運(yùn)作。——史蒂夫·喬布斯。

產(chǎn)品經(jīng)理則要用好UML，從而抽象出運(yùn)作邏輯。

作者：擎蒼，《“圖解”產(chǎn)品：產(chǎn)品經(jīng)理業(yè)務(wù)設(shè)計(jì)與UML建模》作者，公眾號(hào)：圖解產(chǎn)品設(shè)計(jì)

本文由 @圖解產(chǎn)品設(shè)計(jì) 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議