导读：这是餐饮系统大拆除三篇。 第一篇使用类图分解了员工信息。 在第二篇中，我们使用类图分解了套餐和桌子信息。 本文利用类图分解订单信息，考虑订单的异常。 同样，也谈《图解产品》这本书里没有写的知识，读书需要那本书的知识背景。
01用户点餐流程用户点餐。 他可以在网上主动下单，也可以在现场由服务员代为下单。 为了说明主要问题，我们只考虑服务器下单的情况，其操作流程如下。
柜台(服务员点击柜台打开柜台，表示该桌子已经被客人使用下单)服务员操作下单系统，代替客人下单)服务员点击订单将订单信息发送到厨房。 订单信息在厨房被清算)用户吃完后，前台确认已被清算)清洁工打扫桌子，然后，服务员点击清空柜台，客人就可以在下一张桌子上吃饭了，服务员的操作流程为了便于理解，这个过程已经简化了。
那么，现在的问题是如何考虑订单的各种情况。
这里有三种方法：用例驱动、进程驱动和域驱动。 这三种方法都要运用，才能考虑全面。
在《图解产品》这本书里，用例驱动和过程驱动的故事很多，但领域驱动的故事很少。 本文谈区域驱动这一方法。
按照02领域主导的类图《图解产品》这本书的知识，可以整理订单的类图。 整理方法是看竞争产品和进行用户采访。 书中还阐述了具体步骤。 下图是用这种方法组织的结果。
该图表示订单由订单项目(菜单项)、支付信息和发票信息等构成。 如果你没读过书，我就简单解释一下这张图。
线两侧的数字表示两个类之间的数量关系，更准确地说是对象之间的数量关系)。 如果该系统支持对一个订单进行多项支付，用户可以同时使用购物卡和微信，共同支付一个订单。
为什么要整理数量关系？ 因为这会影响原型的设计。 如果一个订单支持多项支付，界面需要显示购物卡扣除的金额和微信支付的余额。
但是，上图减少了订单和桌子之间的数量关系。 两者之间的数量关系是什么？
03订单与桌子的关系根据《图解产品》的思路分析，订单与桌子之间必须是多对多的关系。 这意味着一个订单可以与多个表相关联，一个表也可以与多个订单相关联。
如果一个订单有多个关联的表，例如公司的人一起吃饭，则可能需要同时占用多个表。 如果一张桌子有多张订单，一张桌子只有一位客人坐的时候，第二位客人也允许在这张桌子上吃饭，也就是搭桌，那么一张桌子就会有多张订单。
这种多对多的关系，我们也必须体现在原型中。
但是，还不够。 我们必须根据表格信息考虑TA对订单的影响。 这意味着您需要枚举类型为“表”的信息。 例如，桌子的属性是位置、是否有单间费用、能坐多少人等。 桌子的状态包括空闲、不空闲(打开、正在清洁等)、维护等状态。
然后，根据表中的这些信息，周密考虑订单的逻辑。
例如，不空的桌子不能重新订购。 但是，如果允许摆桌子的话，也可以再点一张。 此外，用户的就餐人数(按订单反应)应小于该桌人数。 不一致时需要注意。 最后，如果这张桌子有单间费用的话请累计到订单上。 另外，如果一张订单，一张桌子有房费，另一张桌子没有房费，需要考虑应该如何计算费用。
总之，需要考虑订单和表信息之间的各种交叉情况，即一对多、多对多等情况。 考虑不完全的话，有可能导致研究开发的返工，所以请特别重视。
是的，这就是今天的内容。 总之学好UML的话，想法会变得周到，可以避免修改！ 希望正文对你有帮助，全文结束！
TIPS :
也有人认为设计就是看起来是什么样的。 但是，深入挖掘就会发现，设计与它是如何工作的有关。 ——史蒂夫乔布斯。
产品经理必须使用UML来抽象操作逻辑。
作者：擎苍，《“图解”产品：产品经理业务设计与UML建模》作者，公众号：图文产品设计
这篇文章发表在@图解产品设计的原创每个人都是产品经理。 未经许可禁止转载。
标题来自Unsplash，基于CC0协议
