背景

幾年前我總結過DDD戰術設計的一些落地經驗可落地的DDD(5)-戰術設計，和一次關于聚合根的激烈討論最近兩年有些新的落地體驗，回過頭來發現，當初對這些概念的理解還是沒有深入，這篇文章重新闡述下，

之前理解不到位的點有

戰術設計的各個模塊是的協作關系
哪些是問題空間問題，哪些是方案空間問題邊界沒有劃分清楚，
物體和聚合根的區別理解不不深刻，物體和聚合根建模的方法不對，

以上問題將會在下文解釋清楚，

戰術設計拆解

DDD的戰術設計即設計某個子域的領域模型以及代碼落地，領域事件、領域物件、聚合根、物體、值物件、領域服務、工廠、資源庫等這些概念都屬于這個范疇，

筆者將這些概念重新分層組裝了下，如下圖所示，

DDD戰術設計-個人理解版 (3).png
首先將整體分成兩部分，問題空間和方案空間，

問題空間即領域建模，是對業務問題的描述，以及我們如何對這些問題進行抽象，這些是需要在業務、產品、開發都必須達成一致的，與具體的技術方案無關，
方案空間即如何用技術手段來解決問題，與具體技術的實作有關，

問題空間即領域建模，是通過物體、值物件、領域服務、領域事件來表達，

物體和值物件是模型物件，物體是重中之重，包括核心模型資料、行為、狀態，之所以要區分物體和值物件，是為了降低復雜度，因為值物件是個常數物件，不需要花太多精力，
注意某個物件在某個領域內是個值物件，在另外的領域可能是個物體，所以脫離領域背景關系，說某個物件是值物件，肯定是不對的，比如大家常說的地址是個值物件，這一定是對的嗎？
領域事件即物體產生的事件
領域服務包括一些邏輯的計算，和業務策略，比如商業決策邏輯、業務流程等，

方案空間即如何解決問題，實作領域模型與代碼的映射，實作設計與實作的一致性，主要通過工廠，聚合，資源庫來表達，

聚合是對物體、值物件的封裝，領域外部對領域物件所有訪問都基于聚合來，如基礎設施層操作聚合進行資料保存，其他領域參考聚合物件資料，
聚合的設計一般是圍繞著技術來的，比如聚合物件事務性，
工廠，復雜物件的創建工廠類
資源庫，對聚合的操作，

從筆者的實踐角度來說，落地DDD程序中，問題空間比方案空間更重要，收益更大，因為通常我們吐槽的某些代碼寫的爛，貧血模型，背后并不是因為沒有用DDD,而是問題空間沒有定義好，對于業務沒有深刻理解，導致模型抽象不足，

如何建模

為什么要建模

通常在某個子域落地DDD，我們會按照業務分析-》用例分析-》領域建模(問題空間) -》技術落地（方案空間）這些步驟來操作，但其實即使我們不在代碼里落地DDD,只用前面3步維護一個子域內的領域模型也同樣能夠帶來很多收益，包括但不限于

統一業務組各個角色的認知，業務、產品、開發大家對同一概念的認知是一致的，
指導開發作業的拆分，

比如在淘寶有個血的教訓，至今這個歷史債還無法被修復，早期在淘寶開店，一個賣家只能開一個店，賣家和店鋪是兩個領域物件，關系是1:1，店鋪服務覺得是1:1的關系，對外提供的服務有根據sellerId獲取店鋪資訊，所以其他呼叫方就無意識的直接參考了賣家id，這樣也可以拿到店鋪，導致shopId被等同于了sellerID，這個誤參考發生在成千上萬個地方，最后導致后續需要支持一個賣家開多店鋪時無法支持，只能通過其他trick方式實作，

以之前介紹過的CRM領域來講解，
省略業務分析，直接拿到用例，