經過前面一段時間的學習，相信你對類目、屬性、商品、促銷、庫存、購物車的業務和設計有了一定的了解。上一章節我們也讨論了結算系統的功能以及業務邏輯。
似乎離送出訂單隻有最後一步了，不過在結算頁面我們并沒有發現需要持久的資訊。那麼訂單到底需要包含哪些資訊呢?今天是訂單的第二個章節，猿人工廠君打算和你聊一聊訂單模型的那些事兒。
猛然一想訂單需要包含哪些資訊，有一點無從下手的感覺，我們可以回頭看看結算頁的設計，或許可以從中尋找一絲規律。
哈哈，又看到這個複雜的調用關系了。結算頁為了展示結算使用的資訊，發生了無比複雜的調用關系。結算頁的一些資訊可以為我們提供幫助。
使用者位址、商品資訊、商家資訊、庫存資訊、促銷優惠、優惠券優惠、運費，這些資訊應該在訂單中展現嗎？在回答這個問題之前，我們可以先聊一聊訂單是個什麼？
訂單是訂購貨物的合同、單據，電商網站的訂單，是消費者和電商網站之間達成的銷售合同。電商網站需要負責向消費者提供合同約定内的商品和服務，而消費者付出應該支付的酬勞。
那麼訂單是合同的展現，自然有買賣雙方了，誰買的，誰賣的，什麼時間以什麼價格買了什麼東西，這些被購買的東西包含了哪些優惠，這些東西的價格構成是什麼樣的，訂單需要什麼時候以什麼方式送達到使用者手中，訂單是以什麼方式來進行支付，訂單需要開具什麼樣的發票資訊，都要白字黑字寫得清清楚楚。
我們從系統層面上分析，會發現有很多資訊可能是經常變化的，比如商品資訊，商品的價格。再比如促銷相關的資訊，一個商品可能現在搞活動，可能過一段時間就不搞活動了，再比如說商家想換一個招牌(名字)，還能不讓他換嗎？
是以從某種層面上來講，訂單資訊能會貫穿全站的核心資訊，并且在下單的一瞬間，記錄的是這些資訊的一個快照。幾乎就是一個繞密碼了：
某人，某一時刻，享受了某些促銷優惠之後，再使用了若幹優惠券，采取了某個支付方式購買了某些商家的商品，并要求使用某些物流供應商的配送服務，将商品送達至某地的某人。
這個繞密碼雖然有些複雜我們也可以一起來分析分析一個訂單到底需要包含哪些資訊，這些關聯關系又是什麼樣的。由于訂單的關系比較複雜，我們先分析訂單次元的一些事情。
從訂單的次元出發，訂單的主要資訊可以分為以下幾類，訂單主資訊，訂單價格資訊，訂單收貨人資訊，訂單優惠券資訊，訂單促銷資訊，訂單運費資訊，訂單發票資訊，為了記錄訂單的一些系統級别和擴充資訊，我們還專門抽象了一個訂單擴充實體用于存儲。
可能有朋友會覺得好奇，甚至産生疑問，為什麼猿人工廠君的每個實體中，都有orderId,parentOrderId,userId,userName,sellerId,sellerName,這幾個固定的字段，而且不嫌棄資訊備援嗎？相信能看懂這幾個字段的朋友，都是有一定電商實際經驗的人士了，暫且賣個關子，一切為了後續擴充，建構系統的時候胃口還是要有的。
接下來講以下訂單這幾個實體的關系，訂單資訊和訂單價格，訂單收貨人資訊，訂單發票資訊，訂單擴充資訊是一對一的關系。訂單資訊和訂單優惠券資訊，訂單促銷資訊，訂單運費資訊是一對多的關系。
聊完了訂單次元的幾個實體，我們一起來聊聊訂單中SKU的那些事情了。我們先用類圖歸納總結一下。
有的同學一定會很好奇，為什麼OrderSku實體有一個屬性叫orderSkuUuid,在一個訂單中，skuId不應該是唯一的嗎？哈哈有經驗的朋友一定不會問這樣的問題，因為如果産生了優惠互斥，一條記錄就沒辦法展現sku的資訊了。是以需要單獨定義一個屬性來表示。
SKU的價格怎麼來表示呢？訂單上SKU的價格資訊，實際上記錄的是，某一個SKU買了多少個的價錢。而不是某一個SKU買了一個的價錢。為什麼會有這樣的問題？我們在講價格計算的時候已經舉過類似的例子了，我們改一下——一個sku買了3個，供貨價總共12塊，優惠2塊，總金額10塊。這個就表示不了每一個了。但是業務确實存在。
關于訂單價格和SKU價格的屬性，其實是一個可以擴充的屬性，新增一種新的優惠，可能需要增加對應的優惠屬性，也許有的小夥伴會問，既然是這樣的話，為什麼不設計為一對多的關系？
其實這是一種扁平化的設計，如果太多的一對多關系，會導緻資料量的急速增加，而采用扁平化的方式來處理，也能很好的應對高速的業務發展。
以上就是訂單實體的一些屬性和關系，在接下來的一章中，我們會講到訂單下單中的一些小秘密。可能你會覺得簡單了些，或者有不同的設計，歡迎你聯系猿人工廠君噢，至于最後的實作，還有詳細設計還有更多的門門道道噢，設計系列完成之後，就是實作了。