對於乙個電商系統而言，**也是蠻基礎的乙個服務。下面我就綜合自己做過的相關業務來談談這個問題。
為什麼我們要從產品的角度來看這個問題？因為從高處來看我們才能對乙個系統有更加深的理解。當然，還有非常重要的一點就是我們需要去了解我們要做的東西即將帶來的價值。
實際上，我們可以從如下的幾個角度來看待**。
**的作用
**的作用實際上和線下的**活動的作用是基本一致的。那就是通過相關的手段來促進到店鋪的流量的轉化率，促進商品的成交率。
**的作用範圍
就目前而言，**的作用範圍以店鋪為緯度，當然，更大維度上就是全平台的**。但是全平台的**我司已經有類似的概念存在，那就是活動。因此，也就沒有必要在做重複的東西。
**的依賴
**作為基本的服務，其服務物件主要是商品，是因為**只是商品的屬性而已，因此，值得說明的是，**將會將商品和**資訊繫結，而後在實際的展示環節將此資訊提供給商品。
下單流程也對此有一定的依賴，因為在最終下單的時候，我們需要去計算最終的乙個訂單金額。
業務總結
如上便是對於業務的乙個總結，實際上首先是要明確**的型別，其次就是對於滿包郵而言的地區限制等等。其他的就沒有什麼說的了！
技術選型
資料庫採用mysql，orm框架採取mybatis，其次當然就是spring全家桶了。包括spring的基本模組以及mvc。
以上的技術選型是比較符合技術選型的一些標準的，也就是說，相關技術比較成熟穩定，在效能上也有著不錯的表現。
資料庫設計
資料庫再設計的時候我們主要需要考慮的是有幾張表，表之間的關聯關係，索引欄位的設立等等。如下，便是設計的模型：
如上我們可以看到大致分為四張表。主表的話儲存的是唯一性的資訊，而商品表和詳情表處於同乙個層級，實際上，而地區資訊表是同**的詳情繫結在一起的。每乙個層級可能都會配置相應的地區資訊。
是否需要快取
快取實際上是乙個大家都在討論的問題，但是當我們引入快取的時候我們一定是要注意兩個點：一就是快取的時效性，二就是採取主動快取還是被動快取。當然，還有一點，我們的專案是否適合快取以及是否有快取的必要性。
是否需要快取我們可以去大致的估算下流量，最主要的介面呼叫應該是商品的頁面的展示，也就是資料庫的大頭是落在查詢上的。這是從資料庫的主要操作來看。其次，商品的詳情頁面的展示應該是電商系統裡面非常活躍的乙個頁面。按照10%到20%的商品有**活動來看的話，這應該也是非常可觀的介面呼叫。因此，從資料的請求量來看，也很有必要。
做乙個系統或業務，實際上我們去審視這個系統，從產品做出來有什麼用到產品的技術實現上我們都要有乙個整體的把握。總結業務的模型、抽象業務的相關模型真的非常重要，這將讓我們的**寫的更快！如果大家有什麼更好的東西可以分享給阿福！
電商後台 促銷中心 邏輯
中心 形式 形式設計測試用例思路 滿減 1.減價的金額不能大於等於商品原價 使用等價類邊界值的方法 2.階梯滿減，下一階梯要大於上一階梯 3.階梯最多設定多少個？單品 價不能高於等於原價 使用等價類邊界值的方法 套裝 商品a和商品b組成套裝的總價不能大於等於原價 贈品 1.贈品最多贈多少件？2.訂單...
小明電商啟示錄 促銷
一 領券次數的設計 領券 表少。查詢量比較大。where條件可能涉及user id,coupon code和activity id。為此要設計多個索引。索引的增加又影響插入效能。二 領取次數的設計 優惠 初始值為最大值，每領取1張減1。只要判斷receive count 0，就可確認是否有資格領取。...
06秒殺系統業務之一 促銷服務
服務在之前的基礎上，進行業務的增加。同時在商品的model中新增乙個 字段promomodel若發現這個商品有 欄位則在 中新增 根據商品id 使用者id,商品的數量，活動id orderservice.createorder usermodel.getid itemid,promoid,amoun...