經過上一章的討論相信你已經有些了解促銷系統了。促銷確實是電商網站的重中之重,需要慎重考慮。也許你會有一些疑問，猿人工廠君給出了促銷規則，但是卻沒有告訴你限購怎么來玩耍。 這個問題我們稍微放一放，考慮到每個人的基礎不一樣，在后面的文章中會一定會體現出來的。今天，我們一起來聊一聊電商網站的價格是怎么一回事情。

猿設計同樣是一個原創系列文章，幫助你從一個只是具備一些技術名詞的小白猿人，開始掌握一些行業內通用的設計系統方法，提高你需求挖掘、需求分析、系統分析和設計的能力，完成屬于你的能力聚變，設計系列完成，帶你擼一個真電商出來，更多精彩內容，敬請大家關注公主號猿人工廠，點擊猿人養成獲取！

說起價格二字，你一定會覺得好奇，價格有什么好講的啊，之前促銷的設計不是已經講過了嗎（看下圖），都已經知道價格是由促銷系統來控制的了。

確實如此，比如用戶訪問商品詳情頁面，商品詳情獲取商品信息后，根據類目、SPU、SKU等信息，從讓促銷系統去計算，從而獲取商品的優惠以及價格。而這個價格的調控，我們是通過商品上的商品“供貨價”來做為價格基數，和促銷系統發生聯系來調控的。從這個層面上來講，似乎價格確實是由促銷系統來決定。

但是，在下這個結論之前，我們來先考慮以下幾個事情。用戶的哪些行為會和價格發生關系？嗯，商品詳情頁。已經說過了，用戶需要看到。購物車頁面，用戶要看到價格，才知道買什么，買多少吧。結算頁面，要付款了，不知道價格，不是坑人嗎？提交訂單，下單不需要后端的價格計算嗎？頁面提交的價格就一定正確嗎？

我們可以通過畫圖的方式，來梳理下上述幾個頁面的流程，商品詳情頁面已經畫過了，暫時略過。

從上面的圖中可以很清晰的看出來，用戶會很多場景會看見商品的價格。而這些場景并不相同，對應的業務也不相同。但是，有一個共性——用戶需要價格。那么如果某一天，價格系統的計算邏輯需要發生了變化，而其它系統也必然發生變化，從而導致計算邏輯的改變。

我們可以看一下，商品詳情頁需要修改,結算頁需要修改，購物車需要修改，訂單需要修改……而這些修改將帶來大量的資源成本和時間成本。很多系統在考慮設計的時候（比如一些開源的，還有某些機構的），并沒有考慮單獨考慮價格這個問題，從而決定了demo永遠只能是demo……

所以，價格應該獨立于商品、類目、促銷等等模塊來說，是勢在必行的一個事情。我們可以看一下，價格獨立設計之后帶來的影響。

看見了吧?所有的和錢相關的事情，由價格系統/模塊處理，其余的系統/模塊只用關注價格系統/模塊的接口就好了。而價格計算的邏輯，由價格系統/模塊去完成即可。價格相關的邏輯變化，是價格系統/模塊內部的事情，不要再麻煩其它人了，而其它人也不必再關注這個事情了。無論從運營上，以及維護的人力和時間成本來看，這樣無疑是一個更優解。

接下來，我們就聊一聊價格系統/模塊，本身有什么職責以及和促銷之間又有什么聯系呢。價格系統/模塊，獨立之后，自然就是為大家提供價格服務了，因為所有的人都等著他的回答xxx,多少錢。這個問法自然有所不同了。我們大致可以考慮為下面的用例。

從具體的場景分析，價格計算的設計可以考慮為兩個方面的事情，第一是根據單個類目ID、SKUID獲取價格，第二是根據類目ID、SKUID批量獲取價格。從程序的精度和實時性的要求上來講，訂單價格計算和結算頁價格計算對價格的要求更高，而詳情和購物車，相對低一些，在設計時可以分開考慮。

也許你覺得價格計算比較簡單，不值得區別對待，那么接下來，我們要來聊一個有趣的事情。說有3個SKU分別為A，B，C，供貨價（商品原價）均為4塊。現在A，B，C，一起購買參加了一個滿10塊減2塊的活動，一起購買需要10塊錢。問，A，B，C的實際售價是多少？

嗯，好嘛，2塊錢的優惠，每個sku優惠了0.6666元，那四舍五入，每個3.34元，這樣一來，總價就是10.02元了，說好的十塊錢呢，奸商嗎？那每個sku都是3.33元，這樣一來，總價就是9.99元了，說好的十塊呢？少的那一分研發出嗎？這個問題看過來，猿人工廠君教你破法。

先用除法快速計算出平均優惠數（小數點后兩位四舍五入），然后根據sku種類累加優惠總數，如果累加總數等于優惠總數，那么每個sku的價格為sku原價-平均優惠數，如果累加總數等于優惠總數，則需要隨機一個sku來補足優惠差額。

正是因為類似的事情還有很多，所以價格計算需要獨立出來單獨設計，這還僅僅是業務上的一個劃分，至于為了保證性能的一些改造，等我們業務層面的設計完成之后，在后續的實現中，再給大家講解。

我建了一個技術群，群里有很多高手，加小編微信，備注：學習。帶你見識更多的高手，幫你快速成長。