天猫交易系统的过去,现在和未来  by tianqi@天猫
交易线是个神马?•   交易包括三个部分:•   购物篮•   下单•   订单详情
交易线做神马?• 支持整站的交易行为• 为垂直业务线作支持,例如IPAD,线下 体验店。• 为垂直市场特殊业务作支持,例如电器 城家装馆服务,跨店活动优惠。
交易线的特殊性• 业务逻辑 杂• 价格计算必须一分不差• 前后端耦合严重,通过接口耦合
积分换购    积分加钱购                   货到付款单品优惠   数量                             免邮                 运费险    运费   店铺优惠             ...
前后端耦合
前后端耦合普通的耦合
前后端耦合        VM由   发维护,里面有大量后台业务逻辑,例如为了普通的耦合   呈现某一块内容,   发书写了大量ifelse,其实这部分
前后端耦合        VM由   发维护,里面有大量后台业务逻辑,例如为了普通的耦合   呈现某一块内容,   发书写了大量ifelse,其实这部分接口的耦合
前后端耦合        VM由   发维护,里面有大量后台业务逻辑,例如为了普通的耦合   呈现某一块内容,    发书写了大量ifelse,其实这部分        大量使用接口,在一条整体逻辑中,前端负责一部接口的耦合   分,    发...
前后端耦合        VM由   发维护,里面有大量后台业务逻辑,例如为了普通的耦合   呈现某一块内容,    发书写了大量ifelse,其实这部分        大量使用接口,在一条整体逻辑中,前端负责一部接口的耦合   分,    发...
前后端耦合        VM由   发维护,里面有大量后台业务逻辑,例如为了普通的耦合   呈现某一块内容,    发书写了大量ifelse,其实这部分        大量使用接口,在一条整体逻辑中,前端负责一部接口的耦合   分,    发...
价格计算以服务为例,其中一条非常小的子线                   初始化,   发计算服务价格                                    改变服务选择 改变数量        商品价格   服务单价   ...
历史-里程碑尝试独立    线上下单    购物篮 选型     订单详情   活动优惠摸索很痛苦    服务    代码小范围重构家装馆下单
历史-遗留问题
历史-遗留问题  逻辑清晰了,但是维护困难,模块化不
历史-遗留问题过度模块化   逻辑清晰了,但是维护困难,模块化不
历史-遗留问题过度模块化   逻辑清晰了,但是维护困难,模块化不逻辑混乱
历史-遗留问题过度模块化   逻辑清晰了,但是维护困难,模块化不逻辑混乱        至今仍然没有整理清楚所有逻辑。文档
历史-遗留问题过度模块化    逻辑清晰了,但是维护困难,模块化不逻辑混乱         至今仍然没有整理清楚所有逻辑。文档前端逻辑太多
历史-遗留问题过度模块化    逻辑清晰了,但是维护困难,模块化不逻辑混乱         至今仍然没有整理清楚所有逻辑。文档前端逻辑太多         大量逻辑控制在前端,代码混乱,容易
历史-遗留问题过度模块化    逻辑清晰了,但是维护困难,模块化不 逻辑混乱         至今仍然没有整理清楚所有逻辑。文档前端逻辑太多         大量逻辑控制在前端,代码混乱,容易扩展性和性能
历史-遗留问题过度模块化    逻辑清晰了,但是维护困难,模块化不 逻辑混乱         至今仍然没有整理清楚所有逻辑。文档前端逻辑太多         大量逻辑控制在前端,代码混乱,容易扩展性和性能   逻辑和耦合造成扩展性较差。性能也较
现在
现在 动手术!
前后端解耦    前端负责展现                    发负责数据前端维护最基本的逻辑               初始数据                初始订单结构数据只负责展现和交互               数据接口  ...
逻辑整理项目   始之前, 个周整理时间效果:随意口述,说一条交互,口头算出价格文档化,交互       系图表,特殊逻辑说明等等。跟主线功能无联动         系的抽取,模块化。主线逻辑耦合太深,作为整体模块,而附加功能通过独立模块化插入...
性能优化去多余逻辑去iframe    选择地址后   步刷新所有数据,本地重新   染,   少请求和服务器   染压力逐步    染?基本:数据+模板->基本框架-> 染到浏览器->更多数据+计算订单总价等信息->完整的dom->绑定事件 ...
扩展性代码的扩展性主要是模块化的方式,按照功能模块化,还是视觉模块化?将交互频繁和联系紧密的部分放在一个模块中。但是要提供足   活的接口,根据以往项目的经验,预期未来一段时间内需要   些类型的接口将组件抽象化可遇见的组件:选择地址,运费和优...
前端平台化?尝试各业务线维护自己的模板和js但是   发提供的数据是一致的,不同的只是模板和部分逻辑
交易的将来• 完善文档,清晰逻辑,稳定的代码,易于维护。• 稳定,安全,抗破坏。• 交互   杂但性能卓越,扩展性强,更优雅的界面和交 互效果。• 更好支持各垂直业务,平台化,将工作量分散,提高 效率。
THANKS
天祁《交易线》
天祁《交易线》
Upcoming SlideShare
Loading in …5
×

天祁《交易线》

516 views

Published on

  • Be the first to comment

  • Be the first to like this

天祁《交易线》

  1. 1. 天猫交易系统的过去,现在和未来 by tianqi@天猫
  2. 2. 交易线是个神马?• 交易包括三个部分:• 购物篮• 下单• 订单详情
  3. 3. 交易线做神马?• 支持整站的交易行为• 为垂直业务线作支持,例如IPAD,线下 体验店。• 为垂直市场特殊业务作支持,例如电器 城家装馆服务,跨店活动优惠。
  4. 4. 交易线的特殊性• 业务逻辑 杂• 价格计算必须一分不差• 前后端耦合严重,通过接口耦合
  5. 5. 积分换购 积分加钱购 货到付款单品优惠 数量 免邮 运费险 运费 店铺优惠 送积分服务 使用积分数量 商品 积分加钱购 子订单 活动优惠 商品 分期付款在UI上 活动订单 商品有所体 子订单 主订单 商品现的逻 商品辑 子订单 商品
  6. 6. 前后端耦合
  7. 7. 前后端耦合普通的耦合
  8. 8. 前后端耦合 VM由 发维护,里面有大量后台业务逻辑,例如为了普通的耦合 呈现某一块内容, 发书写了大量ifelse,其实这部分
  9. 9. 前后端耦合 VM由 发维护,里面有大量后台业务逻辑,例如为了普通的耦合 呈现某一块内容, 发书写了大量ifelse,其实这部分接口的耦合
  10. 10. 前后端耦合 VM由 发维护,里面有大量后台业务逻辑,例如为了普通的耦合 呈现某一块内容, 发书写了大量ifelse,其实这部分 大量使用接口,在一条整体逻辑中,前端负责一部接口的耦合 分, 发负责一部分,二者通过接口交互,其实前端
  11. 11. 前后端耦合 VM由 发维护,里面有大量后台业务逻辑,例如为了普通的耦合 呈现某一块内容, 发书写了大量ifelse,其实这部分 大量使用接口,在一条整体逻辑中,前端负责一部接口的耦合 分, 发负责一部分,二者通过接口交互,其实前端逻辑的耦合
  12. 12. 前后端耦合 VM由 发维护,里面有大量后台业务逻辑,例如为了普通的耦合 呈现某一块内容, 发书写了大量ifelse,其实这部分 大量使用接口,在一条整体逻辑中,前端负责一部接口的耦合 分, 发负责一部分,二者通过接口交互,其实前端 大量业务逻辑堆积在前端,前端的逻辑和代码比 发逻辑的耦合 只多不少
  13. 13. 价格计算以服务为例,其中一条非常小的子线 初始化, 发计算服务价格 改变服务选择 改变数量 商品价格 服务单价 服务总价 切换优惠 子订单价格 活动订单价格 主订单的价格
  14. 14. 历史-里程碑尝试独立 线上下单 购物篮 选型 订单详情 活动优惠摸索很痛苦 服务 代码小范围重构家装馆下单
  15. 15. 历史-遗留问题
  16. 16. 历史-遗留问题 逻辑清晰了,但是维护困难,模块化不
  17. 17. 历史-遗留问题过度模块化 逻辑清晰了,但是维护困难,模块化不
  18. 18. 历史-遗留问题过度模块化 逻辑清晰了,但是维护困难,模块化不逻辑混乱
  19. 19. 历史-遗留问题过度模块化 逻辑清晰了,但是维护困难,模块化不逻辑混乱 至今仍然没有整理清楚所有逻辑。文档
  20. 20. 历史-遗留问题过度模块化 逻辑清晰了,但是维护困难,模块化不逻辑混乱 至今仍然没有整理清楚所有逻辑。文档前端逻辑太多
  21. 21. 历史-遗留问题过度模块化 逻辑清晰了,但是维护困难,模块化不逻辑混乱 至今仍然没有整理清楚所有逻辑。文档前端逻辑太多 大量逻辑控制在前端,代码混乱,容易
  22. 22. 历史-遗留问题过度模块化 逻辑清晰了,但是维护困难,模块化不 逻辑混乱 至今仍然没有整理清楚所有逻辑。文档前端逻辑太多 大量逻辑控制在前端,代码混乱,容易扩展性和性能
  23. 23. 历史-遗留问题过度模块化 逻辑清晰了,但是维护困难,模块化不 逻辑混乱 至今仍然没有整理清楚所有逻辑。文档前端逻辑太多 大量逻辑控制在前端,代码混乱,容易扩展性和性能 逻辑和耦合造成扩展性较差。性能也较
  24. 24. 现在
  25. 25. 现在 动手术!
  26. 26. 前后端解耦 前端负责展现 发负责数据前端维护最基本的逻辑 初始数据 初始订单结构数据只负责展现和交互 数据接口 大部分特殊业务逻辑维护一个固定的数据结构无逻辑的前端模板 解耦的最终目标,是前端只负责展现,而且能保存最纯洁的数据 结构,不管如何交互,前端只 心后台需要谁的属性值,我需要 后台返回谁的新的属性值,而不 心其中的具体逻辑。数据结构 不会增加新的标示。
  27. 27. 逻辑整理项目 始之前, 个周整理时间效果:随意口述,说一条交互,口头算出价格文档化,交互 系图表,特殊逻辑说明等等。跟主线功能无联动 系的抽取,模块化。主线逻辑耦合太深,作为整体模块,而附加功能通过独立模块化插入主线,通过接口交互。
  28. 28. 性能优化去多余逻辑去iframe 选择地址后 步刷新所有数据,本地重新 染, 少请求和服务器 染压力逐步 染?基本:数据+模板->基本框架-> 染到浏览器->更多数据+计算订单总价等信息->完整的dom->绑定事件 通过接口 步更新数据后->尽量更新最小涉及范围最大需求满足的数据以及DOM。梦想:还没想好
  29. 29. 扩展性代码的扩展性主要是模块化的方式,按照功能模块化,还是视觉模块化?将交互频繁和联系紧密的部分放在一个模块中。但是要提供足 活的接口,根据以往项目的经验,预期未来一段时间内需要 些类型的接口将组件抽象化可遇见的组件:选择地址,运费和优惠的下拉框。后续可能会做大的优化,例如自定义组件,还有ipad等平台上的特殊定制。将组件抽象化,当做一个虚拟对象,以询问和回答的方式实现。
  30. 30. 前端平台化?尝试各业务线维护自己的模板和js但是 发提供的数据是一致的,不同的只是模板和部分逻辑
  31. 31. 交易的将来• 完善文档,清晰逻辑,稳定的代码,易于维护。• 稳定,安全,抗破坏。• 交互 杂但性能卓越,扩展性强,更优雅的界面和交 互效果。• 更好支持各垂直业务,平台化,将工作量分散,提高 效率。
  32. 32. THANKS

×