经过前面一段时间的学习，相信你对类目、属性、商品、促销、库存、购物车的业务和设计有了一定的了解。上一章节我们也讨论了结算系统的功能以及业务逻辑。
似乎离提交订单只有最后一步了，不过在结算页面我们并没有发现需要持久的信息。那么订单到底需要包含哪些信息呢?今天是订单的第二个章节，猿人工厂君打算和你聊一聊订单模型的那些事儿。
猛然一想订单需要包含哪些信息，有一点无从下手的感觉，我们可以回头看看结算页的设计，或许可以从中寻找一丝规律。
哈哈，又看到这个复杂的调用关系了。结算页为了展示结算使用的信息，发生了无比复杂的调用关系。结算页的一些信息可以为我们提供帮助。
用户地址、商品信息、商家信息、库存信息、促销优惠、优惠券优惠、运费，这些信息应该在订单中体现吗？在回答这个问题之前，我们可以先聊一聊订单是个什么？
订单是订购货物的合同、单据，电商网站的订单，是消费者和电商网站之间达成的销售合同。电商网站需要负责向消费者提供合同约定内的商品和服务，而消费者付出应该支付的酬劳。
那么订单是合同的体现，自然有买卖双方了，谁买的，谁卖的，什么时间以什么价格买了什么东西，这些被购买的东西包含了哪些优惠，这些东西的价格构成是什么样的，订单需要什么时候以什么方式送达到用户手中，订单是以什么方式来进行支付，订单需要开具什么样的发票信息，都要白字黑字写得清清楚楚。
我们从系统层面上分析，会发现有很多信息可能是经常变化的，比如商品信息，商品的价格。再比如促销相关的信息，一个商品可能现在搞活动，可能过一段时间就不搞活动了，再比如说商家想换一个招牌(名字)，还能不让他换吗？
所以从某种层面上来讲，订单信息能会贯穿全站的核心信息，并且在下单的一瞬间，记录的是这些信息的一个快照。几乎就是一个绕口令了：
某人，某一时刻，享受了某些促销优惠之后，再使用了若干优惠券，采取了某个支付方式购买了某些商家的商品，并要求使用某些物流供应商的配送服务，将商品送达至某地的某人。
这个绕口令虽然有些复杂我们也可以一起来分析分析一个订单到底需要包含哪些信息，这些关联关系又是什么样的。由于订单的关系比较复杂，我们先分析订单维度的一些事情。
从订单的维度出发，订单的主要信息可以分为以下几类，订单主信息，订单价格信息，订单收货人信息，订单优惠券信息，订单促销信息，订单运费信息，订单发票信息，为了记录订单的一些系统级别和扩展信息，我们还专门抽象了一个订单扩展实体用于存储。
可能有朋友会觉得好奇，甚至产生疑问，为什么猿人工厂君的每个实体中，都有orderId,parentOrderId,userId,userName,sellerId,sellerName,这几个固定的字段，而且不嫌弃信息冗余吗？相信能看懂这几个字段的朋友，都是有一定电商实际经验的人士了，暂且卖个关子，一切为了后续扩展，构建系统的时候胃口还是要有的。
接下来讲以下订单这几个实体的关系，订单信息和订单价格，订单收货人信息，订单发票信息，订单扩展信息是一对一的关系。订单信息和订单优惠券信息，订单促销信息，订单运费信息是一对多的关系。
聊完了订单维度的几个实体，我们一起来聊聊订单中SKU的那些事情了。我们先用类图归纳总结一下。
有的同学一定会很好奇，为什么OrderSku实体有一个属性叫orderSkuUuid,在一个订单中，skuId不应该是唯一的吗？哈哈有经验的朋友一定不会问这样的问题，因为如果产生了优惠互斥，一条记录就没办法体现sku的信息了。所以需要单独定义一个属性来表示。
SKU的价格怎么来表示呢？订单上SKU的价格信息，实际上记录的是，某一个SKU买了多少个的价钱。而不是某一个SKU买了一个的价钱。为什么会有这样的问题？我们在讲价格计算的时候已经举过类似的例子了，我们改一下——一个sku买了3个，供货价总共12块，优惠2块，总金额10块。这个就表示不了每一个了。但是业务确实存在。
关于订单价格和SKU价格的属性，其实是一个可以扩展的属性，新增一种新的优惠，可能需要增加对应的优惠属性，也许有的小伙伴会问，既然是这样的话，为什么不设计为一对多的关系？
其实这是一种扁平化的设计，如果太多的一对多关系，会导致数据量的急速增加，而采用扁平化的方式来处理，也能很好的应对高速的业务发展。
以上就是订单实体的一些属性和关系，在接下来的一章中，我们会讲到订单下单中的一些小秘密。可能你会觉得简单了些，或者有不同的设计，欢迎你联系猿人工厂君噢，至于最后的实现，还有详细设计还有更多的门门道道噢，设计系列完成之后，就是实现了。
