共计 660 个字符，预计需要花费 2 分钟才能阅读完成。
滴滴网页车订单的开发票页面，见下方截图。业务操作大家应该都知道，勾选一笔或多笔订单，点击“下一步”进行开发票。
滴滴网约车日订单量有 1 千多万。在技术层面，如何设计，来让开票业务最大程度上减少对订单表的耦合呢？
先来回顾一下滴滴网约车订单大致的开票流程。
| 开票页面，用户勾选订单 | → | 点击“下一步”，申请开票 | ||
| ↑ | ↓ | |||
| ↑ ↑ ↑ ↑ | 进入开票详情页 选择发票类型， 填写开票信息、 选择发票接收方式 | |||
| ↑ | ↓ | |||
| 开票异常，重开发票 | ← | 点击“提交”，确认提交开票 | → | 开票历史查询 （即：查询已开票记录） |
我们先来看看“需求直译”模式的实现方式：
- 订单表上增加字段 是否开票。
- 开票页面 展示 是否开票 =false 的订单。
- 订单发生开票后，保存开票主表和开票订单表，同时设置订单的 是否开票 =true。
- 订单开票失败后，重置订单的 是否开票 =false。
- 开票历史查询页，查询 开票主表和开票订单表。
其中，关于开票主表和开票明细表，开票主表保存开票信息，如发票类型、开票信息、发票接收方式，开票订单表保存开票时所选择的订单。开票主表与开票订单表 在系统里 以 开票单号 来关联（滴滴查询已开票记录时，并未展示这个开票单号，毕竟用户不关注这个东东，可见滴滴产品在用户体验上的拿捏还是很到位的）。
缺点是很明显的。
从程序设计方面来说，开票与订单产生耦合。因开票业务，需要修改订单的 是否开票 字段。
从系统性能方面来说，滴滴的订单量大，因此而产生的对订单表的 update 操作会影响订单表性能。这个比较要命。
变换一下思路，我们来看看更好的实现方式，让开票与订单彻底解耦。
首先，在订单完成时，。。。（待续，你琢磨琢磨）
正文完
