很多时候，系统的开发建设是以需求驱动的，在做了很多形态的电商业务之后，有时候也可以反其道而行之，用技术的角度和思维去建设一些系统，可能会收到不一样的效果，需求永远都是跟着现实的需要而随着变化，但如何跳出为了单一的需求变化站在技术的角度去思考如何以不变应万变的系统建设思路？

从订单中心的职能来看，主要承接交易的达成，衔接起从交易、支付、履约到售后各个业务活动的流转，订单中心是电商业务的核心，起到承上启下的作用，上游通过对用户、商品、供应商、门店等涉及的各个交易参与方的整合，完成从成单到支付的交易动作，下游链接起履约、售后、资金、营销等，完成从货物履约、资金结算到逆向售后，是电商各个活动的重要参与方。

从整个业务活动周期来看，订单一般会经历下单、支付、配送/履约以及售后等各个环节，每个环节均可能涉及订单的状态流转，经历一个业务活动，伴随着业务活动的结束，状态也从A驱动到B。

从整个业务类型来看，传统电商为代表的阿里，有天猫(B2C)、淘宝(C2C)、聚划算、团购、闲鱼、盒马生鲜等，以本地生活为代表的美团，有闪购、外卖、酒旅、票务、美团优选等，各个业务形态各不尽相同，流程也各有差异。

从交易的本质的来看，如果没有线上，回归现实世界看待交易本质，无外乎就是买卖双方的钱与货(服务)交换的一个过程，而订单就好像是双方因为某种约定(货物或服务)所签订的契约关系，是作为后续业务活动的凭据。

当我们更了解了交易的本质之后，不难理解订单其实就是一个合同，而合同将伴随着业务活动至此业务结束，那么从技术角度来看，无非就是需要解决以下技术问题。

1、不同的业务，合同将是不同的，如何设计出统一的合同要素能供各个业务形态去使用？

2、状态的流转将涉及到不同的业务事件，如何设计出基于业务事件驱动的状态机流转？

3、订单协同上游商品、门店、供应商等各个交易关系方，在微服务的体系中，如何设计出统一的服务编排能力？

4、不同的业务，其合同的履约形式千差万别，有实物商品类的，也有服务类，还有虚拟的电子券类的，逆向售后环节也各不尽相同，如何设计出统一的流程驱动组件的能力？

5、订单作为下游业务活动的源头，如何满足各个业务系统的数据诉求，如何设计出基于统一的订单消息组件？

这样一归纳整理之后，跳出纷繁错杂的业务世界的时候，发现订单其本质就是去设计出统一的订单模型去承载合同签订；设计出统一的状态机引擎去满足基于业务事件驱动的状态流转；设计出统一的服务编排去整合上游各个交易关系方；设计出统一的流程组件去适配不同业务形态之间的流程差异；设计出统一的消息适配能力去满足不同下游业务对于订单的诉求等等。

有时候换一个角度去思考系统建设，可能会看到不一样的世界，对于现实中的业务变化我们无法去穷举，用技术人最擅长的组件化、引擎化思维去构建一个不一样的订单中心。在这里，不打算去讲解各个技术组件如何去实现，因为这些技术组件有太多的最佳实践案例，也有非常多的开源组件去供大家参考和学习。