滴滴网约车订单的开发票页面,见下方移动端页面截图。业务操作大家应该都知道,勾选一笔或多笔订单,点击“下一步”进行开发票。
滴滴网约车日订单量有1千多万。在技术层面,如何设计,来让开票业务最大程度上减少对订单表的耦合呢?
先来回顾一下滴滴网约车订单大致的开票流程。
开票页面,用户勾选订单 | → | 点击“下一步”,申请开票 | ||
↑ | ↓ | |||
↑ ↑ ↑ ↑ | 进入开票详情页 选择发票类型, 填写开票信息、 选择发票接收方式 | |||
↑ | ↓ | |||
开票异常,重开发票 | ← | 点击“提交”,确认提交开票 | → | 开票历史查询 (即:查询已开票记录) |
我们先来看看“需求直译”模式的实现方式:
- 订单表上增加字段 是否开票。
- 开票页面 展示 是否开票=false 的订单。
- 订单发生开票后,保存开票主表和开票订单表,同时设置订单的 是否开票=true。
- 订单开票失败后, 重置订单的 是否开票=false。
- 开票历史查询页,查询 开票主表和开票订单表。
其中,关于开票主表和开票明细表,开票主表保存开票信息,如发票类型、开票信息、发票接收方式,开票订单表保存开票时所选择的订单。开票主表与开票订单表 在系统里 以 开票单号 来关联(滴滴查询已开票记录时,并未展示这个开票单号,毕竟用户不关注这个东东,可见滴滴产品在用户体验上的拿捏还是很到位的)。
缺点是很明显的。
从程序设计方面来说,开票与订单产生耦合。因开票业务,需要修改订单的 是否开票 字段。
从系统性能方面来说,滴滴的订单量大,因此而产生的对订单表的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跳转。