餐饮系统大拆解，理清订单与桌台之间的各种异常(3)

导读：这是餐饮系统大拆解第三篇。在第一篇中，我们用类图拆解了员工信息；在第二篇中，我们用类图拆解了套餐和桌台信息；本篇将用类图拆解订单信息，从而将订单的异常考虑全。同样，本文也会讲《图解产品》一书中未讲的知识，且阅读本文需有该书的知识背景。

01用户下单流程

用户要点餐，他既可在网上自主下单，还可在现场由服务人员代为下单。为说明主要问题，我们只考虑由服务员下单这种情况，而其操作流程是：

• 开台：服务员点击开台，表示该桌台已经被顾客使用

• 点餐：服务员操作点餐系统，代顾客点餐

• 下单：服务员点击下单，订单信息下发到厨房

• 结账：用户吃完后到前台结账，收银员确认该用于已结账

• 清台：保洁员清理桌台，之后服务员点击已经清台，则下桌客人就可用餐了

以上，就是服务员的操作流程。为了便于理解，该流程做了简化。

那现在的问题是，如何将订单的各种情况都考虑全？

这里有三个方法，分别是用例驱动、流程驱动和领域驱动。这三个方法都要运用，才能考虑全面。

在《图解产品》一书中，用例驱动和流程驱动讲的较多，但领域驱动讲的少。本文就说说领域驱动这个方法。

02 领域驱动下的类图

按照《图解产品》一书的知识，你就可以梳理出订单的类图，梳理的方法有：看竞品和进行用户访谈，书中还讲了具体的步骤。下图就是是按此方法梳理出来的结果。

该图表达了订单是由订单项（菜单的条目），支付信息与发票信息等组成的。如果你没有看过书，我简单解释一下该图。

在线条两边的数字，表示两个类之间的数量关系，更准确地是对象间的数量关系）。如该系统支持一个订单可以有多个支付，即用户可同时使用购物卡和微信，来共同支付一个订单。

为什么要梳理数量关系？因为这将影响原型设计。如一个订单支持多个支付，那么在界面上，就要显示购物卡抵扣的金额，再加上需要用微信支付的余额。

但上图少了订单与桌台之间的数量关系，请你思考一下，两者之间的数量关系是什么？

03 订单与桌台关系

按照《图解产品》的思路分析，订单与桌台之间应为多对多的关系。即一个订单可以关联多个桌台，且一个桌台也可以关联多个订单。

一个订单关联多个桌台的情况，如是公司的人一起吃饭，这就可能需要同时占用多个桌台。一个桌台有多个订单的情况，当一个桌子只坐了一位客人，如允许第二个客人也在这个桌子上吃饭，也就是允许拼桌，则一个桌台就有多个订单。

而这个多对多的关系，我们也要在原型里体现出来。

但这还不够，我们还应基于桌台信息，再考虑TA对订单的影响，即需要将“桌台”这个类的信息列出，如桌台的属性有：位置、是否有包间费用，可坐几人等；桌台的状态有：空闲、非空闲（已开台、正清洁等）、维修等状态。

然后基于桌台的这些信息，再将订单逻辑考虑周到。

• 比如，非空闲的桌台是不能再下单的。但如允许拼桌，则也可再下一单。

• 再如，用户的就餐人数（在订单里反应）应小于该桌台人数，如不符合就要有提醒。

最后，如该桌台有包间费则应累计到订单中。同时还需考虑一个订单下，如果一个桌台有包间费，另一个桌台无包间费，又应如何计算费用。

总之，你需要考虑订单与桌台信息之间个各种交叉情况，即一对多，多对多等情况。如考虑不全，就可能导致研发重做，所以尤其要重视。

好了，这就是今天的内容。总之学好UML，就能考虑周全，避免返工！希望本文能帮到你，全文完！

TIPS：

有些人认为设计就是看起来长什么样。但是如果你深入挖掘就会发现，设计更关乎如何运作。——史蒂夫·乔布斯。

产品经理则要用好UML，从而抽象出运作逻辑。

作者：擎苍，《“图解”产品：产品经理业务设计与UML建模》作者，公众号：图解产品设计

作者 @图解产品设计

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！