导读：这是餐饮系统大拆解第三篇。在第一篇中，我们用类图拆解了员工信息；在第二篇中，我们用类图拆解了套餐和桌台信息；本篇将用类图拆解订单信息，从而将订单的异常考虑全。同样，本文也会讲《图解产品》一书中未讲的知识，且阅读本文需有该书的知识背景。
01用户下单流程
用户要点餐，他既可在网上自主下单，还可在现场由服务人员代为下单。为说明主要问题，我们只考虑由服务员下单这种情况，而其操作流程是：
- 开台：服务员点击开台，表示该桌台已经被顾客使用
- 点餐：服务员操作点餐系统，代顾客点餐
- 下单：服务员点击下单，订单信息下发到厨房
- 结账：用户吃完后到前台结账，收银员确认该用于已结账
- 清台：保洁员清理桌台，之后服务员点击已经清台，则下桌客人就可用餐了
以上，就是服务员的操作流程。为了便于理解，该流程做了简化。
那现在的问题是，如何将订单的各种情况都考虑全？
这里有三个方法，分别是用例驱动、流程驱动和领域驱动。这三个方法都要运用，才能考虑全面。
在《图解产品》一书中，用例驱动和流程驱动讲的较多，但领域驱动讲的少。本文就说说领域驱动这个方法。
02 领域驱动下的类图按照《图解产品》一书的知识，你就可以梳理出订单的类图，梳理的方法有：看竞品和进行用户访谈，书中还讲了具体的步骤。下图就是是按此方法梳理出来的结果。
该图表达了订单是由订单项（菜单的条目），支付信息与发票信息等组成的。如果你没有看过书，我简单解释一下该图。
在线条两边的数字，表示两个类之间的数量关系，更准确地是对象间的数量关系）。如该系统支持一个订单可以有多个支付，即用户可同时使用购物卡和微信，来共同支付一个订单。
为什么要梳理数量关系？因为这将影响原型设计。如一个订单支持多个支付，那么在界面上，就要显示购物卡抵扣的金额，再加上需要用微信支付的余额。
但上图少了订单与桌台之间的数量关系，请你思考一下，两者之间的数量关系是什么？
03 订单与桌台关系按照《图解产品》的思路分析，订单与桌台之间应为多对多的关系。即一个订单可以关联多个桌台，且一个桌台也可以关联多个订单。
一个订单关联多个桌台的情况，如是公司的人一起吃饭，这就可能需要同时占用多个桌台。一个桌台有多个订单的情况，当一个桌子只坐了一位客人，如允许第二个客人也在这个桌子上吃饭，也就是允许拼桌，则一个桌台就有多个订单。
而这个多对多的关系，我们也要在原型里体现出来。
但这还不够，我们还应基于桌台信息，再考虑TA对订单的影响，即需要将“桌台”这个类的信息列出，如桌台的属性有：位置、是否有包间费用，可坐几人等；桌台的状态有：空闲、非空闲（已开台、正清洁等）、维修等状态。
然后基于桌台的这些信息，再将订单逻辑考虑周到。
- 比如，非空闲的桌台是不能再下单的。但如允许拼桌，则也可再下一单。
- 再如，用户的就餐人数（在订单里反应）应小于该桌台人数，如不符合就要有提醒。
最后，如该桌台有包间费则应累计到订单中。同时还需考虑一个订单下，如果一个桌台有包间费，另一个桌台无包间费，又应如何计算费用。
总之，你需要考虑订单与桌台信息之间个各种交叉情况，即一对多，多对多等情况。如考虑不全，就可能导致研发重做，所以尤其要重视。
好了，这就是今天的内容。总之学好UML，就能考虑周全，避免返工！希望本文能帮到你，全文完！
TIPS：
有些人认为设计就是看起来长什么样。但是如果你深入挖掘就会发现，设计更关乎如何运作。——史蒂夫·乔布斯。
产品经理则要用好UML，从而抽象出运作逻辑。
作者：擎苍，《“图解”产品：产品经理业务设计与UML建模》作者，公众号：图解产品设计
本文由 @图解产品设计 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议
,
