我們以電商**的支付功能為例，來重新演練一下基於 ddd 的軟體設計及其變更的過程。
以往當拿到這個需求時，開發人員往往草草設計以後就開始編碼，設計質量也就不高。
而採用領域驅動的方式，在拿到新需求以後，應當先進行需求分析，設計領域模型。 按照以上業務場景，可以分析出：
最後，我們對訂單可以進行「下單」「付款」「檢視訂單狀態」等操作。因此形成了以下領域模型圖：
有了這樣的領域模型，就可以通過該模型進行以下程式設計：
通過領域模型的指導，將「訂單」分為訂單 service 與值物件，將「使用者」分為使用者 service 與值物件，將「商品」分為商品 service 與值物件……然後，在此基礎上實現各自的方法。
第一次需求變更增加折扣功能：並且該折扣功能分為限時折扣、限量折扣、某類商品的折扣、某個商品的折扣與不折扣。
當我們拿到這個需求時應當怎樣設計呢？很顯然，在 payoff() 方法中去插入 if 語句是不 ok 的。
這時，按照領域驅動設計的思想，應當將需求變更還原到領域模型中進行分析，進而根據領域模型背後的真實世界進行變更。
付款與折扣是什麼關係呢？你可能會認為折扣是在付款的過程中進行的折扣，因此就應當將折扣寫到付款中。這樣思考對嗎？我們應當基於什麼樣的思想與原則來設計呢？這時，另外乙個重量級的設計原則應該出場了，那就是「單一職責原則」。
單一職責原則：軟體系統中的每個元素只完成自己職責範圍內的事，而將其他的事交給別人去做，我只是去呼叫。
總之，單一職責原則要求我們在維護軟體的過程中需要不斷地進行整理，將軟體變化同乙個原因的**放在一起，將軟體變化不同原因的**分開放。 按照這樣的設計原則，回到前面那個案例中，那麼應當怎樣去分析「付款」與「折扣」之間的關係呢？只需要回答兩個問題：
當「付款」發生變更時，「折扣」是不是一定要變？
當「折扣」發生變更時，「付款」是不是一定要變？
當這兩個問題的答案是否定時，就說明「付款」與「折扣」是軟體變化的兩個不同的原因，那麼把它們放在一起，放在同乙個類、同乙個方法中，合適嗎？不合適，就應當將「折扣」從「付款」中提取出來，單獨放在乙個類中。
同樣的道理：
當「限時折扣」發生變更的時候，「限量折扣」是不是一定要變？
當「限量折扣」發生變更的時候，「某類商品的折扣」是不是一定要變？
最後發現，不同型別的折扣也是軟體變化不同的原因。將它們放在同乙個類、同乙個方法中，合適嗎？通過以上分析，我們做出了如下設計：
其他需求變更：也採用上面的判斷方式進行擴充套件。並加上介面卡模式進行優化
電商支付流程的 返回 邏輯
注 標題有點繞口，先來做一番解釋 我們在電商平台進行交易的過程中，待到支付環節的時候，假如使用者這時強制選擇 返回 之後頁面如何該跳轉，以及訂單該如何處理？文 產品範 這個問題 於這段時間負責的電商專案，關於頁面跳轉邏輯日常的和開發進行了一番撕逼，開發堅持認為應該原路返回，堅決站在使用者的角度 允許...
電商 支付 支付流水表與訂單表的設計
一.支付流水表 作用 主要用於記錄每一次的支付動作，主要用於，記錄使用者是否有重複支付，重複支付或者過期支付，可以用於檢查，然後退款。二訂單表 1.說訂單表，一般都是主表和子表兩個結構。1.1主表記錄買家買了什麼？付款是多少錢？總的優惠是多少？還有要發往 的位址？1.2子表主要記錄賣家的資訊，賣的是...
電商ERP常見功能模組
電商erp是適用企業賣家的專業電子商務erp，支援 天貓 京東 1688 噹噹 蘇寧 拍拍 唯品會 亞馬遜 獨立b2c等多網路銷售渠道 也包括 異地多倉 貨位管理 智慧型配貨等專業的wms 倉庫管理系統 功能 1.訂單管理 訂單篩選與批量處理 客審與財審結合的雙重審核機制 根據設定規則自動新增贈品 ...