[[400603]]

DDD即領域驅動設計，是一種建模方法論，強調通過分析建模、再設計實現，而不是數據庫表驅動。

DDD解決的是核心復雜業務設計，特別強調的是“核心”與”復雜”，DDD只適用于業務系統。

DDD簡化業務系統的實現，讓業務邏輯高度內聚，聚合之間通過聚合根ID引用與領域事件松耦合，正是高內聚低耦合能讓項目代碼隨著業務需求的不斷迭代保持整潔。

通過四層架構設計/六邊形架構設計實現與基礎設施、框架的解偶。

DDD也解決了微服務的拆分問題。

DDD解決的是業務問題，通過事件風暴識別領域事件、識別限界上下文、識別問題子域、聚合，再對聚合建模。并非解決數據查詢問題、數據分析問題。

前面我們了解了如何通過CQRS解決讀寫分離問題，然而……

在實戰DDD過程中我們總會遇到一些即不適合領域建模也不能簡單通過CQRS解決的問題，如為前端提供住址、性別等選項的接口如何實現、用戶標簽功能如何設計、評價功能如何設計……

對于這些看似簡單的問題，我們要考慮的是如何避免過度設計，保持架構的簡潔以及擴展。

為前端提供選項有非常多的場景。有些選項是個枚舉類型，如性別、訂單類型;有些選項需要支持增加或刪除，如商品分類，雖然實體需要通過ID引用它，但卻又不適合作為實體存在。

無論是枚舉類型的選項，還是通過ID引用卻又不適合作為實體存在的選項，都應該作為值對象。可以直接在應用層讀寫存儲/緩存中間件，如mysql、es、redis。

下文中會出現的領域(業務)名詞：達人：網紅、紅人，有粉絲群體的個人、有一定影響力的個人;OTO探店：線上報名線下探店，線上推廣(主要服務美食點，為商家推廣線下店鋪);

我們項目中有需要實現為達人打標簽的需求，在接到這個需求時，我們首先做的就是分析標簽能產生什么樣的價值，再通過事件風暴看是否能分析出領域事件。

結合項目業務分析，達人標簽在我們項目中發揮的價值其實就是用于興趣匹配推送，在OTO探店業務場景下，興趣匹配可以理解為根據達人喜好的口味給達人推送相關店鋪的訂單。

分析到這里我們就清楚了標簽功能要做的就是數據分析還有算法推薦，除此之外，標簽沒有任何領域事件(行為、業務動作)，標簽不存在領域上下文，所以不應該過度設計。

另外，為達人打標簽/達人自己打標簽，那么標簽就是達人的值對象，與達人的性別、年齡、住址等屬性都是達人的值對象。達人可以添加標簽或者刪除標簽。

所以最終我們實現的標簽功能就只是在達人的聚合根上添加一個標簽值對象。給達人聚合根添加修改標簽的方法。

另外我們需要為前端提供標簽選項，支持管理員添加或刪除標簽，與實現普通選項一樣，我們單獨在達人聚合下提供一個應用層的LableService，直接操作數據庫增/刪標簽。

標簽表的存在只是提供標簽選項，達人給自己打標簽只能從系統提供的標簽中選擇，標簽相當于只是選項。因此達人的標簽值對象并非存標簽的id，而是直接存標簽的名稱。

當標簽選項刪除時我們不應該為所有打了該標簽的用戶默認刪除他的標簽，這實際是不允許的，就像我們不能隨便改用戶的性別、住址一樣。

只有在達人更新標簽時不提供已經刪除的選項，讓達人自己選擇新的標簽更新，更新后舊的標簽全部被替換也就達到刪除的目的。

除選項、標簽外，我們要做的還有一個評價功能。

根據事件風暴我們分析出以下領域事件： a、達人完成任務后商家可評價達人(每個任務只允許評價一次) b、商家評價達人后更新達人的得分(如內容質量得分) "商家評價達人"涉及到任務、達人、商家三個維度，達人可以查看商家給自己的評價，商家也可以查看自己給哪些達人寫了評價，并且都能查看任務關聯的評價。

顯然，無論是把評價功能放到任務上下文還是達人上下文、商家上下文，都不合理。因此我們為評價劃分出評價上下文，識別出評價問題子域。 商家評價達人作為評價上下文的一個聚合，后期可能還會實現支持達人評價店鋪，而達人評價店鋪又是一個評價上下文的聚合，評價上下文存在多個聚合。

我們在實戰DDD過程中，在實現前端選項、標簽功能、評價功能過程中也做了詳細的分析再設計，目的都是避免過度設計。

不斷摸索……