引言

相信通過前面幾篇文章的介紹，大家對于 DDD 的相關理論以及實踐的套路有了一定的理解，但是理解 DDD 理論和實踐手段是一回事，能不能把這些理論知識實際應用到我們實際工作中又是另外一回事，因此本文通過實際的業務分析把之前文章中涉及的理論和手段全部帶著大家走一遍，我想通過這種方式，讓大家實際的感受下 DDD 落地過程中會遇到哪些問題以及我們應該怎樣去解決這些問題。

項目需求信息

這里還是大家比較熟悉的電商場景來進行說明，我想這樣大家比較好理解一點。在前段時間雙十一，大家被各種購物優惠券的套路整的眼花繚亂，仿佛數學不好，都不配拿到最優惠的價格了。大家都在吐槽，就不能少點套路，買東西直接給我 5 折不就天下太平了嗎？我想造成這種現象的原因大概就是中國電商行業的內卷吧，只有通過各種營銷活動的堆積，才能讓大家花更多的時間去瀏覽更過的商品，才能獲得更好的留客以及交易。好了，跑題了，這些我們先不去關心。那我們今天就用這個折磨人的優惠券的流程作為設計實例來說明整個 DDD 的落地過程吧。優惠券的關鍵業務流程如下：

（1）當需要進行大促活動的時候，運營同學需要選定對應的商品，創建創建優惠券。

（2）運營同學需要創建營銷活動，制定對應的營銷活動規則，比如什么滿減啊，跨店減啊類似這種折磨人腦細胞的規則，然后關聯相應的優惠券，最后提交活動審批。審批通過后，進行營銷活動發布。

（3）提交活動審批后，審批進行營銷活動審批。

（4）用戶在營銷頁面領取優惠券之后，下單購買商品之后，在付款的時候根據對應的優惠券進行付費金額計算并完成支付。

DDD落地實踐

項目背景信息我們大致了解之后，那么我們就要著手開始通過ＤＤＤ來進行領域驅動設計的過程了。其實我們學習 DDD 理論以及方法不是最終的目的，而通過它實現實際的業務復雜度治理以及優化微服務設計才是真正的目的。

戰略設計

在戰略設計階段，我們最主要的過程大致包括了業務場景分析、領域建模、劃分邊界上下文三個階段。實際上戰略設計是 DDD 過程中的核心步驟。

業務分析

在這個階段我們所有做的就是進行全面的業務梳理，吧業務中涉及到的所有細節都梳理出來，為后續進行領域建模分析提供足夠的、全面的業務輸入。經常使用到的業務場景分析方法主要包括用例分析法、事件風暴法以及四色建模法。這里我們使用事件風暴進行業務場景的分析以及梳理。

（1）事前準備

在進行事件風暴之前我們需要進行一些準備，主要包括貼紙、筆以及討論的會議室，會議室中最好不要有椅子，目的是想讓大家都能夠站立在一起、全神貫注的去進行業務討論。

（2）邀請參會的人

會議的參與方主要包括業務、用戶、PD、研發、測試、架構師等。

（3）業務討論

首先確定我們今天需要討論的業務是什么，目標是什么。像前文所說的那樣，本次討論的業務就是營銷活動的優惠券業務，目標就是完成優惠券的業務梳理，確保沒有業務方面的理解 gap，在團隊中達成業務理解的的一致性。在這個過程中我們需要通過提問的方式來驅動交流。

a、分析業務中的事件，搞清楚事件發生的前因后果，什么意思呢？就是什么動作會導致當前時間的發生，當前這個事件發生后又會導致怎樣的后果。這些我們都需要梳理清楚。還有一點需要注意， 我不但要關注正常的業務流程還要關注異常的業務流程。

b、尋找業務邏輯和業務規則，比如我們在提交活動前，需要確定這些優惠券適用哪些人、領取方式是怎樣的以及生效事件是怎樣的等等，這些都是我們在執行操作之前需要確定的業務規則。

如下圖所示，我們將優惠券的業務流程進行了梳理，分別從操作人、事件、命令的方式來描述整個優惠券業務流轉的過程。

注：在進行事件風暴過程中，所有的參與人都要全身投入整個過程，放下手機以及電腦，一起參與整個業務梳理過程，只有這樣，事件風暴才可能有比較好的效果。

領域建模

在前面的事件風暴業務梳理中，我們已經把優惠券業務涉及到的參與者、動作以及事件等都進行了全面的梳理。那么接下來我們就要在此基礎之上進行領域建模，這是整個 DDD 的核心。

（1）領域對象分析

如上面所示的事件風暴小黑板中的內容，我們需要在這些梳理出來的內容中找到對應的實體、值對象以及圍繞這些的領域事件以及命令操作。根據分析，我們總整個業務過程中提取了優惠券、營銷活動、活動審批單、活動規則、審批意見等實體以及值對象以及和這些領域對象相關的命令操作。

（2）構建業務聚合

完成領域對象分析之后，我們需要構建業務聚合。想要構建聚合，那么首先就要在實體中找到聚合根。我們先來回顧下聚合根的特點，聚合根一定是實體，那么它具有全局唯一的標識，另外它是具備生命周期的同時需要專門的模塊來進行管理。根據這樣的標準，在領域對象中我們發現優惠券、營銷活動以及活動審批單是具備聚合根特征的，而營銷規則、營銷內容等是和營銷活動緊密相關的，因此他們構成營銷活動聚合關系。優惠券規則、優惠券類型等是和優惠券聚合根緊密相連的，所以他們構成優惠券聚合關系。同理活動審批單也會構成聚合關系。最終我們形成如下的聚合關系。

劃分邊界上下文

獲得了整個業務流程中的所有聚合后，我們需要更具業務語義上下文將具體的聚合劃分到對應的上下文中，因此我們可以把優惠券的業務分為優惠券、營銷活動以及審批三個限界上下文。

戰術設計

在戰略設計階段，我們通過事件風暴法對整體的業務進行了全部的梳理，同時構建了領域模型以及劃分了邊界下文。那么接下來我們就要將領域模型映射到工程結構以及代碼中實現最終的實現落地。另外在這個階段實際還有很多細節需要明確，那優惠券來說，它包含哪些屬性，需要哪些領域服務，哪些需要設計為實體，哪些需要設計為值對象，這些都是需要在戰術設計階段明確下來。

微服務拆分

我們根據已經劃分的邊界上下文，我們可以拆分為優惠券服務、營銷活動服務以及審批中心三個微服務，至于用戶支付使用這塊，還是由原先已存在支付服務來完成，只是在付款核算的時候需要使用到優惠券進行最后的金額計算。

領域分層

在領域分層方面，我們還是按照之前文章中所說的分層結構來進行，即 interfaces 層、biz 層、domain 層以及 instructure 層。每層代表的含義之前的文章中已經進行了詳細的說明，大家可以翻看前面文章中的介紹，這里不再進行贅述了。

我們以優惠券為例，實際聚合中對象還需要進行進一步的細化。對于優惠券來說它實際上還有如下所示的值對象以及實體來組成實際的優惠券。同時在優惠券我們的梳理的領域服務還包括創建優惠券、查詢優惠券以及修改優惠券狀態，這些動作實際都應該在領域層通過領域服務的形式完成落地。而對應的 biz 層就相當于業務的編排組合，也就是實際的業務流程的串聯。

代碼結構

當我們把領域對象進行進一步的細化之后，同時把對應的領域服務敲定之后，我們可以把這些分析后的內容映射成工程分層后的代碼了。如下圖所示，即為優惠券的 domain 層的代碼映射。

當然到這里并不意味著結束，其實在后續還有很多工作要做，比如詳細設計、編寫代碼以及功能測試，特別實在詳細設計階段，我們還要涉及很多的細節問題的敲定，比如數據庫表的設計、比如使用什么 MQ，用不用緩存，怎么保證緩存和數據庫的數據一致性問題，分布式服務有沒有分布式事務的問題，應該怎么解決？有沒有服務冪等問題，應該怎么解決？這些都是需要在詳細設計階段進行確定的。因此 DDD 就像是框架，通過它把業務映射成為領域對象以及領域服務和領域事件，再把這些領域相關內容再讀映射為實際的代碼。使得我們的服務更加的邏輯清晰以及擴展性更強，但是分布式的技術實現細節，我們還是需要有對應的解決方案來進行解決。

總結

本文以電商行業的營銷活動中的優惠券的發放和使用作為實際案例來闡述 DDD 領域驅動設計落地實踐的過程，通過整個過程的梳理，為大家提煉了整個設計過程的精要，相信大家可以按照這樣的思路在實際的工作中再結合各自的業務特征應該可以真正完成整個 DDD 的實踐。萬事開頭難，相信只要大家能夠親自去參與或者主導一個 DDD 的落地實踐過程，那么對于理解 DDD 這套架構設計方法論又會進入一個新的臺階。在后面的文章中再和大家聊聊落地 DDD 過程中可能會遇到的一些問題以及軟件復雜度治理的問題。

有道無術，術可成；有術無道，止于術

歡迎大家關注Java之道公眾號

好文章，我在看??

新人創作打卡挑戰賽發博客就能抽獎！定制產品紅包拿不停！

總結

以上是生活随笔為你收集整理的DDD 领域驱动设计落地实践：六步拆解 DDD的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。