底層支撐的模塊，比如，庫存系統、會員系統。這些模塊的特點是，所處理的業務流程相對單壹、閉環，不需要太多依賴外部系統既可以完成領域內的邏輯。
如會員系統最重要的流程就是註冊、登錄、校驗登錄態。這幾個流程基本只依賴會員系統自身，沒有對外部系統產生強依賴，強耦合。
比較復雜的是串業務流程的系統，這部分系統業務邏輯會相對更復雜些，比如商詳或者購物車。因為商祥或者購物車所展示給用戶看到的東西需要串聯非常多的業務模塊，將其中的信息進行封裝組合展示給用戶，這裏的業務邏輯非常復雜，系統內部的交互非常多。
我們以京東的購物車為例，簡單的剖析壹下京東的購物車大體背後的業務邏輯，實現方式。
購物車中所展示的東西，無非就是加入購物車中的商品以及壹些促銷信息。那麽第壹個問題是，這些購物車中的商品、促銷信息是靜態的還是動態獲取的？
所謂靜態就是指用戶在將商品加入購物車的時候，在購物車中存儲加入購物車的商品所需要展示的各種信息。例如上面展示的商品的主圖文描，促銷等等。
動態獲取就是在查看購車的時候，再去實時調用相應的系統獲取最新的信息。
答案是，購物車的數據只會存儲必要的商品信息，其他的信息完全是動態獲取的。
因為在加入購物車的時候如果是靜態存儲的，那麽在下壹次查看購物車的時候，所展示的信息可能就不是最準確的。這中間可能商品信息會發生變化，比如商品被下架了、商品的主圖被調整了、或者主題被修改了、商品的促銷信息也可能會發生變化，在加入購物車的時候可能會命中壹個促銷，但是過了壹段時間之後，這個促銷可能結束了。所以比較精準的做法是在展示購物車的時候，再去實時拉取壹次商品的詳細信息以及當前的最新促銷信息。
但是購物車中還是會存儲壹部分數據，主要存儲哪些數據呢？主要如下圖所示。
那麽下面我們來看壹下，查看購物車背後到底有哪些邏輯？
第壹步首先是校驗會員的登錄態。上面購物車存儲的結構中，我們看到購物車的存儲是以用戶維度進行數據存儲的，所以要展示購物車的時候，首先要拿到用戶的ID。所以這裏第壹步就會校驗登陸態，因為只有用戶登錄後才能識別當前的用戶具體是誰？才可以從購物車的存儲中獲取響應的數據。然後購物車會根據取到的商品ID列表再去實時調用壹次商品系統來獲取最新的商品信息，最終組裝後進行展示。
下壹步是獲取庫存信息。庫存情況由於變更比較頻繁，所以每次查看購物車的時候也需要實時的去查看當前商品的庫存情況。如果購物車中的商品沒有庫存，那麽就要進行提示，如下圖所示，在購物車中將此商品置灰，提示此商品“無貨”。
庫存這裏還有壹個比較特殊的邏輯，就是贈品的邏輯。贈品分為兩種情況，壹種是滿多少元送壹個贈品，簡稱“滿贈”。另外壹個是買壹個東西送壹個贈品，簡稱“買贈”。兩種都是贈品，但是對於庫存的邏輯處理完全不壹樣。
這兩種情況都會要求主商品跟贈品必須要在同壹個倉。不然就會出現主品從壹個倉發貨，贈品從另外壹個倉發貨。要承擔兩份運費的成本。本來就是贈送壹個贈品，如果還需要額外承擔運費的話，那麽肯定不劃算。所以在校驗庫存的時候，壹定會校驗主品跟贈品是否都在同壹個倉有貨
當贈品跟主品不在同壹個倉或者贈品沒貨的時候。對於滿贈這種場景，如果贈品沒有庫存，那麽還是可以正常下單的。因為滿贈這種促銷類型會給用戶進行提示“贈品數量有限，先到先得”。所以贈品沒貨的時候也是可以正常下單的，用戶也是能接受的。但是買贈這種場景，如果贈品沒有貨，那麽會提示用戶贈品無貨，不可以下單。因為這種場景用戶會認為贈品是主品的壹部分，沒有贈品也就不會去買這個主品了。
獲取完庫存之後，下壹步會計算購物車中商品促銷的情況。這也是整個購物車中邏輯最復雜的壹部分。促銷本身就比較復雜，因為會存在多種促銷類型，如果某個商品同時命中多個促銷怎麽辦？如果商家設置了非常多的促銷，每壹次都需要拿購物車中的商品去遍歷計算每個商品命中哪個促銷規則，整個計算過程也非常耗時。所以購物車會將商品列表傳給促銷系統，促銷系統根據購物車中傳遞過來的商品去計算，這些商品會命中哪些促銷，然後將這些商品按照命中的促銷進行分門別類返回給購物車。比如壹個購物車中壹個商家下有若幹個商品。其中兩個命中了a促銷，另外兩個命中了b促銷，還有三個沒有民主促銷。那麽要按照結構返回給購物車，購物車再展示給到用戶，這樣用戶看的會比較清晰些。
在購物車中除了展示基本的商品信息，還有很多額外的功能，比如計算運費。上圖中會顯示這壹個商品包郵免運費。那麽運費是如何計算出來的呢？
其實在商家後臺有壹個叫做運費模板的東西。商家會設置運費的策略，主要分為兩種規則。壹種是根據單個商品去設置運費的規則，壹種是根據訂單維度去設置模板。
單品維度指的是某壹個商家的某個商品在某些地址需要收多少錢運費。這種的應用場景是當商家發現有些商品發到偏遠地區比較貴的時候，會設置這樣壹個單品模板。
比如某個商品發到新疆、西藏、甘肅比較貴，那麽就可以設置這個商品在這三個省收學費15元，反之只要收貨地址不是這三個省的，那麽這個商品就不收運費。
另外壹種是訂單維度的模板，也就是按照訂單維度來計算，整個訂單收多少運費。
舉個例子，比如我們經常見的江浙滬包郵。那麽這個模板應該如何設計呢？首先是選好壹個商家，然後選好江浙滬的地址。在這些地址設置壹個規則訂單，不滿0元運費0元。江浙滬之外需要收10元的運費，那麽再設置壹下，除了江浙滬之外的省份。訂單不滿100元收取10元運費。這樣就達到了江浙滬包郵，江浙滬之外的地區需要有門檻，達到100元不收運費，但是不足100元需要收10元運費。
購物車中每壹個商家頭部有壹個領券的標識。來標識這個商家目前可以有優惠券可以領。這個領券設計的目的是為了讓用戶能夠在最關鍵的環節知道有券可以用，從而提升購物車的轉化率。那麽這個功能是如何做到的呢？
在購物車中會將商品按照商家的維度分成不同的塊。每壹個塊代表壹個商家，商家裏面的商品如果有促銷信息，按照塊的維度再去展示促銷的信息。領券的計算單位是商家的維度，在購物車中首先將商品根據不同的商家計算好分塊之後，每壹個塊都代表壹個商家，購物車會去計算當前商家下面以及當前商家購物車中的商品是否有可以領用的優惠券。如果這個商家制了10個批次的優惠券，其中2個批次的券可以使用當前購物車的商品，並且用戶還沒有領券，那麽就會在這個地方進行提示，告訴用戶有可以領用的券。
購物車中還有壹個叫做預估到手價。之前購物車中只展示了哪些商品可以命中哪些促銷，但是每壹個單品最終成交的價格需要用戶自己去算壹下。由於促銷疊加起來比較復雜，有些用戶自己也算不清楚。所以這個預估到手價就是系統根據當前疊加促銷、券之後算出來的壹個最終成交的價格。這個功能省去了用戶自己去計算的過程，並且很直觀明了的展示出來了，最終的成交價對用戶提升轉化也有很大的幫助。那麽這個預估到手價是如何實現的呢？
首先會先去計算購物車中商品的價格。有沒有單品維度的價格促銷，比如，價格直降或者秒殺、拼團之類的價格優惠。也就是上圖顯示的“119”，這個是價格維度的計算。在計算好單品價格維度之後，會再去計算壹下當前商品是否有命中訂單維度的促銷，比如滿減或者折扣。這個時候會在單品的價格基礎上再減去命中促銷的價格，算出壹個優惠價。然後在這個價格基礎上會再去命中壹次優惠券的邏輯，去看壹下用戶手中有哪些券可以使用。最終再去減去優惠券可以使用的價格，那麽就是用戶實際成交的價格，也就是壹個預估到手價。
這裏舉壹個例子，壹個商品原價100塊。做了壹個價格直降的活動，拼團或者秒殺，價格降到90。然後這個商品還享受了壹個滿減的優惠，滿80減20。這個時候這個單品的價格就變成了90-20=70。如果這個用戶的賬戶中，還有壹張可以用於這個商品的現金10元券。那麽這個商品最終到手的價格就是70元，再減去10元的優惠券等於60元。
通過上面幾個過程，系統就可以幫妳算出來每壹個商品在當前情況下的壹個預估到手的價格。
總結下，購物車是整個電商交易流程中比較復雜的壹個環節，需要串聯會員、商品、庫存、促銷、優惠券等大部分邏輯進行最終的購物車的呈現。為了保證購物車展示給用戶信息的準確性，購物車只存了最基本的壹些信息，絕大部分的信息都是在用戶查看購物車那壹剎那實時計算出來的。