滴滴网约车订单的开发票页面，见下方移动端页面截图。业务操作大家应该都知道，勾选一笔或多笔订单，点击“下一步”进行开发票。

滴滴网约车日订单量有1千多万。在技术层面，如何设计，来让开票业务最大程度上减少对订单表的耦合呢？

先来回顾一下滴滴网约车订单大致的开票流程。

我们先来看看“需求直译”模式的实现方式：

1. 订单表上增加字段 是否开票。
2. 开票页面 展示 是否开票=false 的订单。
3. 订单发生开票后，保存开票主表和开票订单表，同时设置订单的 是否开票=true。
4. 订单开票失败后， 重置订单的 是否开票=false。
5. 开票历史查询页，查询 开票主表和开票订单表。

其中，关于开票主表和开票明细表，开票主表保存开票信息，如发票类型、开票信息、发票接收方式，开票订单表保存开票时所选择的订单。开票主表与开票订单表 在系统里 以 开票单号 来关联（滴滴查询已开票记录时，并未展示这个开票单号，毕竟用户不关注这个东东，可见滴滴产品在用户体验上的拿捏还是很到位的）。

缺点是很明显的。

从程序设计方面来说，开票与订单产生耦合。因开票业务，需要修改订单的 是否开票 字段。

从系统性能方面来说，滴滴的订单量大，因此而产生的对订单表的update操作会影响订单表性能。这个比较要命。

变换一下思路，我们来看看更好的实现方式，让开票与订单彻底解耦。

​首先，在订单完成时，。。。（待续，你琢磨琢磨）

扩展阅读：人人都是产品经理号上，产品经理解读→6个方面解析：滴滴的开发票流程

【业务场景】会补贴员工移动端，点击商家应用图标，会跳转到外部的商家应用。

UI原型如下图。

技术实现方面，因为涉及到跨系统交互，并且要携带登陆用户信息，这里呢，网页跳转到外部应用需要一个网页授权码。那么，前端需要调用后端一个接口。

【初始技术方案】

后端提供的这个接口是——获取网页授权码

请求示例：/user/auth_code?appId=xxx

返回值示例： { "code": 200, "msg": "处理成功", "result": {"source":"SBY_HUIBUTIE", "authCode":"daSdmasldlaslgMkgnj"}}

前端拿到返回的这个authCode后，拼接应用URL，做302跳转。

【升级后的技术方案】

后端提供的这个接口是——获取授权页URL

请求示例：/user/auth_code?appId=xxx

返回值示例： { "code": 200, "msg": "处理成功", "result": {"url":"https://www.demoapp.com/?source=SBY_HUIBUTIE&auth_code=daSdmasldlaslgMkgnj"}}

前端拿到返回的这个URL后，直接做302跳转。

【对比来看，升级的方案更具有设计感！】