市面上订单系统架构的文章有很多，有很多好的思路可以参考，甚至可以激发出新的灵感。但是每一家的业务模式都有自己的特色，因此每一家的订单系统也会有自己的个性化设计思路。以自家公司业务模式展开概述，做为一个平台综合服务商当前公司的业务线有十几个，可归类为两大类：商品&服务，其中商品可分为：实物商品&虚拟商品；服务可分为：人工代订服务、OTA服务。很多业务都是对接的第三方供应商，而且由于业务特性差别较大，因此基本每个业务类型都需要有独立的系统去和第三方对接，另外还有礼券系统、虚拟货币、会籍体系等系统提供运营支撑，这些系统在订单生成的过程中都不可或缺而且有直接影响。对于订单交易整体可总结如下：
前端：用户在前端选择商品或服务——提交订单并完成交易——收到商品或享受服务——查看订单进度和明细——申请售后——查看售后进度和售后详情。
订单系统：是订单链路的核心，其核心功能是将各个零散的、独立的系统功能整合，得出最终的订单。此订单是经营分析、财务账务处理、用户售后申请的重要凭证。
交易中心：包括收银台和订单支付，不耦合任何业务逻辑，只提供纯粹的订单支付功能。
底层模块：此部分包含各个独立的基础功能。
各业务系统：可以理解为各个业务的商品来源并提供下单用户基本信息，例如火车票系统，提供车票信息、保险信息、乘车人、下单用户等；电商系统提供商品、下单用户、地址信息等；电影票系统提供电影票、购票用户等。
营销系统1：类似与积分系统，下单支付时可直接抵扣现金，一个积分=1块钱。该系统提供积分获取、抵扣、发放和收回等规则。
营销系统2：提供优惠券生成、获取、使用、收回等规则。
营销系统3：会员权益系统，下单支付时可根据不同的等级权益享受不同的折扣。
用户中心：提供用户基本信息及会员等级。
商品中心：当前主要为电商系统提供服务，提供商品基本信息及商家信息等。
物流服务：实物商品订单会涉及到发货，因此需要该模块提供发货、物流信息实时获取、物流状态实时更新的功能。根据平台需求，当前物流服务对接的是第三方，通过接口回传。
以上各个模块的功能介绍都是和订单交易相关的功能，每个模块的全部功能均不限于此。这些模块之间通过消息中心实现信息互通。
可能有些人会觉得没必要拆分这么多模块，但是业务是快速发展、千变万化的，底层架构设计不好，以后只能无限期的整体迭代，这是每家公司都不愿意看到的。但是如果每个业务系统职责划分清楚，各个业务模块分而治之、独自管理，这样内部迭代和规则变更对于模块本身来说是“白盒”，对于其他业务系统只需关注其“黑盒”输出即可，不会影响其他系统，符合业务架构及系统架构设计思想，对公司以后的发展奠定基础。即使要新增底层模块或者砍掉其中一个模块，对于整体来说也不会有太大影响。
先开一个头，详细的订单系统介绍后续逐渐补上，各个系统之间如何交互，信息如何流转、财务如何结算我也在逐步总结。现在我们的订单结构是这样的：
