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