基于公司战略的调整和开发框架的升级换代，也伴随着SOP(面向服务编程)和SOA(面向服务架构)的软件开发思想在公司开发团队中的慢慢深入，最终讨论决定在将现有(旧)的支撑公司业务的项目模块(如：产品，商家和订单...)在进行底层架构升级的同时，要让这个模块在一定程度上可以达到复用性——即它应该可以满足新的栏目('同城网购')的相关需求且适当的考虑未来的需求扩展，它不能跟其它的模块耦合在一起，只负责属于这个模块领域内的数据服务（如：产品模块只用考虑产品相关数据的读写），可以独立公开作为一个服务，且可以满足分布式部署的需求(这个由新的基于CSLA的底层框架管理和决定)。 大概从今年1月份，我决定负责订单系统这块儿的设计和开发，由于中间有一些其它的原因，一直到4月中旬——这期间，我更多的是了解和研究淘宝订单交易的各个流程和相关细节，并做了主体的订单系统领域模型分析，这算是前期'耗时长效率低'的最初版的系统设计，也为后期的详细设计打下了基础和铺垫！
由于之前的订单模块，不是我开发的，也只能负责简单的交易处理，所以除了我从淘宝上做流程和数据分析别无参考；淘宝每天都有很多人在用，我也偶尔上去逛逛买点儿东西，但是如果我不负责这个订单系统的开发，我也不会感受到其流程之“复杂”——复杂背后带来的却是我们热衷使用的良好的“用户体验性”。
淘宝的订单系统很庞大，我目前开发的只仿照了其中65%左右的功能，即：从交易开始到交易结束最主要的的交易流程，像：售后、投诉等暂未实现。相对而言，美团网的订单交易就比较简单，可以算作是包含在淘宝订单交易中的一种特殊订单类型：虚拟物品(代金卷，代金卷即为美团卷)订单。
交易总流程图如下：
点击查看大图
想必你看了上面的总流程图，就会感觉流程之复杂——相对于其它的比较单纯的信息类的数据(如：新闻，产品...)，订单这部分的数据都是有状态且有超时时间，这也是订单系统设计和开发的难点！(会在之后的博客中跟大家分享我在做这个订单系统的设计想法)。
我们平时可能会使用到淘宝、美团和京东等多个电子商务网站里的订单系统，对于使用体验一般大部分都大同小异，这样的话，订单系统的开发到底应该要满足或达到什么样的需求标准？
在满足在线交易“方便、快捷”的基本前提下，让买卖双方在订单系统中能自助(可选择)、人性化比较顺畅安全可靠的完成交易中的各个(买家退款等)流程.
这就是我对上面问题的回答，也是我对自己开发订单系统所定的标准。
这是之前在网上看到的一段内容，同样也是我开发的技术要求指南！
先写到这儿吧，这篇博客算是做个大概的描述；很久没写博客了，这期间一直忙着做这个订单系统的开发，虽然很累，但现在基本上算是开发'成功'结束了，有不少细节需要完善。写此系列的博客，也是希望大家能多提意见并分享你的想法和经验！
相关文章
