基於公司戰略的調整和開發框架的升級換代，也伴隨著SOP(面向服務程式設計)和SOA(面向服務架構)的軟體開發思想在公司開發團隊中的慢慢深入，最終討論決定在將現有(舊)的支撐公司業務的專案模組(如：產品，商家和訂單...)在進行底層架構升級的同時，要讓這個模組在一定程度上可以達到複用性——即它應該可以滿足新的欄目('同城網購')的相關需求且適當的考慮未來的需求擴充套件，它不能跟其它的模組耦合在一起，只負責屬於這個模組領域內的資料服務（如：產品模組只用考慮產品相關資料的讀寫），可以獨立公開作為一個服務，且可以滿足分散式部署的需求(這個由新的基於CSLA的底層框架管理和決定)。 大概從今年1月份，我決定負責訂單系統這塊兒的設計和開發，由於中間有一些其它的原因，一直到4月中旬——這期間，我更多的是瞭解和研究淘寶訂單交易的各個流程和相關細節，並做了主體的訂單系統領域模型分析，這算是前期'耗時長效率低'的最初版的系統設計，也為後期的詳細設計打下了基礎和鋪墊！  　　

　　由於之前的訂單模組，不是我開發的，也只能負責簡單的交易處理，所以除了我從淘寶上做流程和資料分析別無參考；淘寶每天都有很多人在用，我也偶爾上去逛逛買點兒東西，但是如果我不負責這個訂單系統的開發，我也不會感受到其流程之“複雜”——複雜背後帶來的卻是我們熱衷使用的良好的“使用者體驗性”。  　　

　　淘寶的訂單系統很龐大，我目前開發的只仿照了其中65%左右的功能，即：從交易開始到交易結束最主要的的交易流程，像：售後、投訴等暫未實現。相對而言，美團網的訂單交易就比較簡單，可以算作是包含在淘寶訂單交易中的一種特殊訂單型別：虛擬物品(代金卷，代金卷即為美團卷)訂單。

　　 交易總流程圖如下：

　　想必你看了上面的總流程圖，就會感覺流程之複雜——相對於其它的比較單純的資訊類的資料(如：新聞，產品...)，訂單這部分的資料都是有狀態且有超時時間，這也是訂單系統設計和開發的難點！(會在之後的部落格中跟大家分享我在做這個訂單系統的設計想法)。

　　 我們平時可能會使用到淘寶、美團和京東等多個電子商務網站裡的訂單系統，對於使用體驗一般大部分都大同小異，這樣的話，訂單系統的開發到底應該要滿足或達到什麼樣的需求標準？
 　　在滿足線上交易“方便、快捷”的基本前提下，讓買賣雙方在訂單系統中能自助(可選擇)、人性化比較順暢安全可靠的完成交易中的各個(買家退款等)流程.

　　 這就是我對上面問題的回答，也是我對自己開發訂單系統所定的標準。

　　電子交易操作的安全基本要求

• 資訊的保密性
• 交易者身份的認證（確認和鑑別）
• 不可否認性（交易的確定性）
• 資訊的完整性（資訊的準確可靠,不可修改）

　　這是之前在網上看到的一段內容，同樣也是我開發的技術要求指南！

     先寫到這兒吧，這篇部落格算是做個大概的描述；很久沒寫部落格了，這期間一直忙著做這個訂單系統的開發，雖然很累，但現在基本上算是開發'成功'結束了，有不少細節需要完善。寫此係列的部落格，也是希望大家能多提意見並分享你的想法和經驗！