溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要為大家展示了“Java中拆解DDD的示例分析”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“Java中拆解DDD的示例分析”這篇文章吧。
這里還是大家比較熟悉的電商場景來進行說明，我想這樣大家比較好理解一點。在前段時間雙十一，大家被各種購物優惠券的套路整的眼花繚亂，仿佛數學不好，都不配拿到最優惠的價格了。大家都在吐槽，就不能少點套路，買東西直接給我 5 折不就天下太平了嗎？我想造成這種現象的原因大概就是中國電商行業的內卷吧，只有通過各種營銷活動的堆積，才能讓大家話更多的時間去瀏覽更過的商品，才能獲得更好的留客以及交易。好了，跑題了，這些我們先不去關心。那我們今天就用這個折磨人的優惠券的流程作為設計實例來說明整個 DDD 的落地過程吧。優惠券的關鍵業務流程如下：
（1）當需要進行大促活動的時候，運營同學需要選定對應的商品，創建創建優惠券。
（2）運營同學需要創建營銷活動，制定對應的營銷活動規則，比如什么滿減啊，跨店減啊類似這種折磨人腦細胞的規則，然后關聯相應的優惠券，最后提交活動審批。審批通過后，進行營銷活動發布。
（3）提交活動審批后，審批進行營銷活動審批。
（4）用戶在營銷頁面領取優惠券之后，下單購買商品之后，在付款的時候根據對應的優惠券進行付費金額計算并完成支付。
項目背景信息我們大致了解之后，那么我們就要著手開始通過ＤＤＤ來進行領域驅動設計的過程了。其實我們學習 DDD 理論以及方法不是最終的目的，而通過它實現實際的業務復雜度治理以及優化微服務設計才是真正的目的。
在戰略設計階段，我們最主要的過程大致包括了業務場景分析、領域建模、劃分邊界上下文三個階段。實際上戰略設計是 DDD 過程中的核心步驟。
在這個階段我們所有做的就是進行全面的業務梳理，吧業務中涉及到的所有細節都梳理出來，為后續進行領域建模分析提供足夠的、全面的業務輸入。經常使用到的業務場景分析方法主要包括用例分析法、事件風暴法以及四色建模法。這里我們使用事件風暴進行業務場景的分析以及梳理。
在進行事件風暴之前我們需要進行一些準備，主要包括貼紙、筆以及討論的會議室，會議室中最好不要有椅子，目的是想讓大家都能夠站立在一起、全神貫注的去進行業務討論。
會議的參與方主要包括業務、用戶、PD、研發、測試、架構師等。
首先確定我們今天需要討論的業務是什么，目標是什么。像前文所說的那樣，本次討論的業務就是營銷活動的優惠券業務，目標就是完成優惠券的業務梳理，確保沒有業務方面的理解 gap，在團隊中達成業務理解的的一致性。在這個過程中我們需要通過提問的方式來驅動交流。
a、分析業務中的事件，搞清楚事件發生的前因后果，什么意思呢？就是什么動作會導致當前時間的發生，當前這個事件發生后又會導致怎樣的后果。這些我們都需要梳理清楚。還有一點需要注意， 我不但要關注正常的業務流程還要關注異常的業務流程。
b、尋找業務邏輯和業務規則，比如我們在提交活動前，需要確定這些優惠券適用哪些人、領取方式是怎樣的以及生效事件是怎樣的等等，這些都是我們在執行操作之前需要確定的業務規則。
如下圖所示，我們將優惠券的業務流程進行了梳理，分別從操作人、事件、命令的方式來描述整個優惠券業務流轉的過程。
注：在進行事件風暴過程中，所有的參與人都要全身投入整個過程，放下手機以及電腦，一起參與整個業務梳理過程，只有這樣，事件風暴才可能有比較好的效果。
在前面的事件風暴業務梳理中，我們已經把優惠券業務涉及到的參與者、動作以及事件等都進行了全面的梳理。那么接下來我們就要在此基礎之上進行領域建模，這是整個 DDD 的核心。
如上面所示的事件風暴小黑板中的內容，我們需要在這些梳理出來的內容中找到對應的實體、值對象以及圍繞這些的領域事件以及命令操作。根據分析，我們總整個業務過程中提取了優惠券、營銷活動、活動審批單、活動規則、審批意見等實體以及值對象以及和這些領域對象相關的命令操作。
完成領域對象分析之后，我們需要構建業務聚合。想要構建聚合，那么首先就要在實體中找到聚合根。我們先來回顧下聚合根的特點，聚合根一定是實體，那么它具有全局唯一的標識，另外它是具備生命周期的同時需要專門的模塊來進行管理。根據這樣的標準，在領域對象中我們發現優惠券、營銷活動以及活動審批單是具備聚合根特征的，而營銷規則、營銷內容等是和營銷活動緊密相關的，因此他們構成營銷活動聚合關系。優惠券規則、優惠券類型等是和優惠券聚合根緊密相連的，所以他們構成優惠券聚合關系。同理活動審批單也會構成聚合關系。最終我們形成如下的聚合關系。
在上述步驟中，我們獲得了整個業務流程中的所有聚合后，我們需要更具業務語義上下文將具體的聚合劃分到對應的上下文中，因此我們可以把優惠券的業務分為優惠券、營銷活動以及審批三個限界上下文。
在戰略設計階段，我們通過事件風暴法對整體的業務進行了全部的梳理，同時構建了領域模型以及劃分了邊界下文。那么接下來我們就要將領域模型映射到工程結構以及代碼中實現最終的實現落地。另外在這個階段實際還有很多細節需要明確，那優惠券來說，它包含哪些屬性，需要哪些領域服務，哪些需要設計為實體，哪些需要設計為值對象，這些都是需要在戰術設計階段明確下來。
我們根據已經劃分的邊界上下文，我們可以拆分為優惠券服務、營銷活動服務以及審批中心三個微服務，至于用戶支付使用這塊，還是由原先已存在支付服務來完成，只是在付款核算的時候需要使用到優惠券進行最后的金額計算。
在領域分層方面，我們還是按照之前文章中所說的分層結構來進行，即 interfaces 層、biz 層、domain 層以及 instructure 層。每層代表的含義之前的文章中已經進行了詳細的說明，大家可以翻看前面文章中的介紹，這里不再進行贅述了。
我們以優惠券為例，實際聚合中對象還需要進行進一步的細化。對于優惠券來說它實際上還有如下所示的值對象以及實體來組成實際的優惠券。同時在優惠券我們的梳理的領域服務還包括創建優惠券、查詢優惠券以及修改優惠券狀態，這些動作實際都應該在領域層通過領域服務的形式完成落地。而對應的 biz 層就相當于業務的編排組合，也就是實際的業務流程的串聯。
當我們把領域對象進行進一步的細化之后，同時把對應的領域服務敲定之后，我們可以把這些分析后的內容映射成工程分層后的代碼了。如下圖所示，即為優惠券的 domain 層的代碼映射。
當然到這里并不意味著結束，其實在后續還有很多工作要做，比如詳細設計、編寫代碼以及功能測試，特別實在詳細設計階段，我們還要涉及很多的細節問題的敲定，比如數據庫表的設計、比如使用什么 MQ，用不用緩存，怎么保證緩存和數據庫的數據一致性問題，分布式服務有沒有分布式事務的問題，應該怎么解決？有沒有服務冪等問題，應該怎么解決？這些都是需要在詳細設計階段進行確定的。因此 DDD 就像是框架，通過它把業務映射成為領域對象以及領域服務和領域事件，再把這些領域相關內容再讀映射為實際的代碼。使得我們的服務更加的邏輯清晰以及擴展性更強，但是分布式的技術實現細節，我們還是需要有對應的解決方案來進行解決。
以上是“Java中拆解DDD的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
