一、前言

領(lǐng)導(dǎo)：為什么要使用DDD?

河北ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：028-86922220（備注：SSL證書合作）期待與您的合作！

我也苦思冥想，怎么跟領(lǐng)導(dǎo)說咱們從 MVC 升級到 DDD 吧，因為 DDD 代碼結(jié)構(gòu)更加清晰、領(lǐng)域驅(qū)動比測試驅(qū)動開發(fā)更加先進、研發(fā)的兄弟們也更想用用新框架等。

不過這么聊被噴一頓不說，還得說你是過度設(shè)計瞎折騰，咋回事呢?因為沒聊到重點呀，你MVC升級DDD;給業(yè)務(wù)帶來了什么、提升了交付效率嗎、降低了公司研發(fā)成本嗎，都沒有?不僅沒有，你還說為了后期的迭代維護，前期會需要更多的設(shè)計和開發(fā)時間。咋?你是想這一個Q就把我送走嗎，我剛來咱們部門KPI在那懸著，壓的我頭發(fā)都白了!別瞎搞，求穩(wěn)!

那就不搞了嗎?搞哇，不讓搞換領(lǐng)導(dǎo)!但搞之前，要考慮清楚，DDD 不是 Silver Bullet，你有一腔熱血雖好，可是也得知曉 DDD 的設(shè)計原則是什么、它更適合的場景是什么、與 MVC 對比有什么云泥之別。

二、開發(fā)成本

使用 DDD 模式開發(fā)代碼的成本到底在哪?是因為使用 DDD 四層分層結(jié)構(gòu)就比MVC 三層分層結(jié)構(gòu) 更浪費時間嗎?其實并不是，因為四層結(jié)構(gòu)相對于三層結(jié)構(gòu)，反而更好的區(qū)分了代碼所屬職責，在熟悉模塊功能職責后，開發(fā)起來也會更加順暢。

那這里的 DDD 領(lǐng)域驅(qū)動設(shè)計開發(fā)的成本在哪呢?這個成本在于對于一個復(fù)雜系統(tǒng)又尚未在開發(fā)前期就有非常充足的經(jīng)驗來拆分職責邊界、劃分功能領(lǐng)域、明確編排邏輯和對未知流程擴展的把控上，所帶來的風暴模型設(shè)計成本。

而通常使用的 MVC 結(jié)構(gòu)基本不會出現(xiàn)這樣的問題，因為在實際的代碼中，DAO、PO、VO等都是共用的，大家在開發(fā)代碼的時候，像堆泥球一樣面向過程寫代碼，直接串聯(lián)出產(chǎn)品的PRD功能節(jié)點即可，不用過多的思考解耦和內(nèi)聚。

那不是可以設(shè)計模式嗎，這就需要看你是站在哪個維度去思考問題。設(shè)計模式在這里是戰(zhàn)術(shù)問題的，DDD和MVC是確定戰(zhàn)略問題的，有點像是說：“方向不對，努力白費一樣”

那么現(xiàn)在我們再來看這條開發(fā)成本曲線：

架構(gòu)模式，開發(fā)成本曲線

• 與其他兩種分層結(jié)構(gòu)相對比，使用 DDD 的時候，需要在前期投入較多的時間成本來設(shè)計領(lǐng)域建模，所以前期成本會更高一些。
• 但隨著業(yè)務(wù)不斷迭代后的邏輯的復(fù)雜性增加，DDD 系統(tǒng)架構(gòu)所開發(fā)的代碼穩(wěn)定性會更好，也就說明 DDD 更容易擴容和維護。
• 所以框架結(jié)構(gòu)的更換，不是最終增加開發(fā)成本的地方，如果你不做領(lǐng)域建模也不做更多的設(shè)計思考，那么即使是 DDD 的四層架構(gòu)，也能讓你寫出 MVC 的效果。而那些對業(yè)務(wù)場景經(jīng)驗豐富的架構(gòu)師或者研發(fā)人員，已經(jīng)非常明確了各個業(yè)務(wù)功能的職責邊界，要實現(xiàn)一個系統(tǒng)需求需要完成哪些核心領(lǐng)域服務(wù)，在這樣的情況用 DDD 也不會帶來多少開發(fā)成本，反而更加游刃有余了!這就是為什么說，需要領(lǐng)域?qū)＜?，因為專家已?jīng)積累了很多的戰(zhàn)略設(shè)計經(jīng)驗
• 此外使用 DDD 領(lǐng)域驅(qū)動設(shè)計的模式進行開發(fā)，除了解決需求的迭代成本，更多的時候是要面對公司戰(zhàn)略調(diào)整后，系統(tǒng)的交接、人員的更替和新增，都要在原有的工程架構(gòu)下繼續(xù)迭代開發(fā)，否則就要推翻重新做，那樣所面臨的更替成本將更大，同時又是開發(fā)了一個與人員綁定不易于交接維護的工程代碼。

三、架構(gòu)對比

在了解和掌握 DDD 領(lǐng)域驅(qū)動設(shè)計的路上，你一定會碰到兩個抽象的釘子 —— “貧血模型”、“充血模型”：

貧血模型：事務(wù)腳本模式，最早起源于 EJB2，到 Spring 進入開“春”盛世。

充血模型：領(lǐng)域模型模式，2003年提出，一直到《實現(xiàn)領(lǐng)域驅(qū)動設(shè)計》的問世，才開啟了 DDD 的大門。但國內(nèi)直到微服務(wù)、低代碼的興起，才開始 DDD 熱

1. MVC

MVC 分層結(jié)構(gòu)將：“狀態(tài)”(數(shù)據(jù)，成員對象)、“行為“(邏輯、過程)，分離到不同的對象中，只有狀態(tài)的對象(VO -> Value Object) 被稱為貧血模型，只有行為的對象，就是框架分層中常見的Logic/Service/Manager層(對應(yīng)到EJB2中的Stateless Session Bean)

MVC 分層結(jié)構(gòu)

• 以應(yīng)用層 Service 使用 DAO、PO 基礎(chǔ)設(shè)施包裝業(yè)務(wù)邏輯的開發(fā)方式，乍一看以為應(yīng)用層是在對領(lǐng)域建模的實現(xiàn)，”領(lǐng)域?qū)印坝兄S富的對象鏈接，和真正的領(lǐng)域模型也非常類似，但當我們代碼隨著業(yè)務(wù)功能邏輯的逐步實現(xiàn)中會慢慢發(fā)現(xiàn)，我們寫了一堆的 get/set 對象，而他們被反復(fù)交叉使用，沒有與任何領(lǐng)域聚合，也就是不具有任何的行為動作，只是一堆貧血模型對象。
• 這種反模式的設(shè)計，其實完全與面向?qū)ο蟮脑O(shè)計是背道而馳的，面向?qū)ο蟮脑O(shè)計更希望行為和數(shù)據(jù)綁定在一起，與之對比的貧血模型更像是面向過程設(shè)計。
• 在 MVC 分層結(jié)構(gòu)下，所有的行為都被寫入到 Service 對象中，最終你會得到一組事務(wù)處理的過程腳本，從而完美的避開了領(lǐng)域模型設(shè)計所帶來的好處(清晰的職責邊界、聚合的功能服務(wù)、清晰的面向?qū)ο?。

2. DDD

DDD 的分層結(jié)構(gòu)也是面向?qū)ο缶幊痰谋举|(zhì)：”一個對象擁有行為和數(shù)據(jù)“，在領(lǐng)域?qū)影耍簩ο?、聚合對象、倉儲和Service實現(xiàn)。

DDD 分層結(jié)構(gòu)

• DDD 的分層結(jié)構(gòu)更注重 Domain 領(lǐng)域?qū)拥膶崿F(xiàn)，由很薄的應(yīng)用層定義接口和編排接口，由領(lǐng)域?qū)幼鼍唧w的實現(xiàn)。
• 所有的業(yè)務(wù)邏輯都按照各自的職責邊界拆分成一塊塊的功能領(lǐng)域，每一個功能領(lǐng)域都是充血模型的結(jié)構(gòu)的具體實現(xiàn)。
• 那么這樣的代碼最終實現(xiàn)以后，無論在迭代、維護、人員更替，都能很好按照領(lǐng)域設(shè)計文檔找到對應(yīng)的代碼實現(xiàn)進行開發(fā)。

四、設(shè)計原則

首先 DDD 的設(shè)計分為戰(zhàn)略和戰(zhàn)術(shù);

• 戰(zhàn)略設(shè)計：從業(yè)務(wù)視角出發(fā)，建立業(yè)務(wù)領(lǐng)域模型、劃分職責邊界，建立通用語言的界限上下文。頂層戰(zhàn)略設(shè)計構(gòu)建的領(lǐng)域模型結(jié)構(gòu)，是整個服務(wù)后期編排的重點，它確定了功能的職責邊界、聚合、對象等，也就決定了后期服務(wù)戰(zhàn)術(shù)實現(xiàn)的開發(fā)和交付質(zhì)量。重視戰(zhàn)略，才能落地好戰(zhàn)術(shù)!
• 戰(zhàn)術(shù)設(shè)計：從技術(shù)視角出發(fā)，側(cè)重于領(lǐng)域模型的技術(shù)實現(xiàn)，完成功能開發(fā)和交付落地。領(lǐng)域設(shè)計的重點包括：實體、聚合對象、值對象、領(lǐng)域服務(wù)、倉儲，還有一個非常重點的設(shè)計模式。任何一個較為復(fù)雜的領(lǐng)域模型實現(xiàn)都需要考慮設(shè)計模式的使用，否則即使戰(zhàn)略優(yōu)秀，戰(zhàn)術(shù)也能干回 MVC 去。

在以DDD領(lǐng)域驅(qū)動設(shè)計落地的過程中，要依靠領(lǐng)域驅(qū)動設(shè)計的設(shè)計思想，通過事件風暴建立領(lǐng)域模型，合理劃分領(lǐng)域邏輯和物理邊界，建立領(lǐng)域?qū)ο蠹胺?wù)矩陣和服務(wù)架構(gòu)圖，定義符合DDD分層架構(gòu)思想的代碼結(jié)構(gòu)模型，保證業(yè)務(wù)模型與代碼模型的一致性。通過上述設(shè)計思想、方法和過程，指導(dǎo)團隊按照DDD設(shè)計思想完成微服務(wù)設(shè)計和開發(fā)。

拒絕泥球小單體、拒絕污染功能與服務(wù)、拒絕加功能排期一個月

架構(gòu)出高可用極易符合互聯(lián)網(wǎng)高速迭代的應(yīng)用服務(wù)

物料化、組裝化、可編排的服務(wù)，提高人效

要領(lǐng)域驅(qū)動設(shè)計，而不是數(shù)據(jù)驅(qū)動設(shè)計，也不是界面驅(qū)動設(shè)計

要職能清晰的分層，而不是什么都放的大籮筐

DDD 的領(lǐng)域模型設(shè)計，界限內(nèi)的上下文，可以拆分為獨立的微服務(wù)。但不僅要從業(yè)務(wù)視角看問題，也要考慮非業(yè)務(wù)的技術(shù)因素，包括：高性能、安全、團隊、技術(shù)異構(gòu)等，這些非業(yè)務(wù)的技術(shù)因素，也會決定領(lǐng)域模型落地的具體落地。

五、舉個例子

你說我 MVC 不好，你說我 MVC 貧血模型，PO 類不斷的膨脹，但讓我用 DDD 又都是理論，程序員更喜歡看的是已經(jīng)落地的代碼，告訴我怎么干。

為什么這么難落地呢?因為從 MVC 過度到 DDD 描述對比只是積累了 MVC 失敗的教訓(xùn)，但沒有 DDD 成功的經(jīng)驗，所以更多的時候想落地 DDD 除了有理論支撐，更需要一份案例擺在面前。

1. 工程結(jié)構(gòu)

所以為了讓更多的碼農(nóng)看到在 DDD 上一條能走的路，專門折騰了個 DDD 分布式抽獎系統(tǒng)，來告訴大家怎么使用 DDD 開發(fā)業(yè)務(wù)需求;

DDD 分布式抽獎系統(tǒng)，工程分布

整體系統(tǒng)架構(gòu)設(shè)計包含了6個工程：

• Lottery：分布式部署的抽獎服務(wù)系統(tǒng)，提供抽獎業(yè)務(wù)領(lǐng)域功能，以分布式部署的方式提供 RPC 服務(wù)。
• Lottery-API：網(wǎng)關(guān)API服務(wù)，提供;H5 頁面抽獎、公眾號開發(fā)回復(fù)消息抽獎。
• Lottery-Front：C端用戶系統(tǒng)，vue H5 lucky-canvas 大轉(zhuǎn)盤抽獎界面，講解 vue 工程創(chuàng)建、引入模塊、開發(fā)接口、跨域訪問和功能實現(xiàn)
• Lottery-ERP：B端運營系統(tǒng)，滿足運營人員對于活動的查詢、配置、修改、審核等操作。
• DB-Router：分庫分表路由組件，開發(fā)一個基于 HashMap 核心設(shè)計原理，使用哈希散列+擾動函數(shù)的方式，把數(shù)據(jù)散列到多個庫表中的組件，并驗證使用。
• Lottery-Test：測試驗證系統(tǒng)，用于測試驗證RPC服務(wù)、系統(tǒng)功能調(diào)用的測試系統(tǒng)。

2. 流程拆解

當我們拿到產(chǎn)品的 RPD 以后，并不是直接上手開發(fā)，而是需要從流程中拆解出一份面向?qū)ο笤O(shè)計的領(lǐng)域服務(wù)，舉例;

DDD 分布式抽獎系統(tǒng)，流程拆解

• 拆解功能流程，提煉領(lǐng)域服務(wù)，一步步教會你把一個業(yè)務(wù)功能流程如何拆解為各個職責邊界下的領(lǐng)域模塊，在通過把開發(fā)好的領(lǐng)域服務(wù)在應(yīng)用層進行串聯(lián)，提供整個服務(wù)鏈路。
• 通過這樣的設(shè)計和落地思想，以及在把流程化的功能按照面向?qū)ο蟮乃悸肥褂迷O(shè)計模式進行設(shè)計，讓每一步代碼都變得清晰易懂，這樣實現(xiàn)出來的代碼也就更加易于維護和擴展了。
• 所以，你在這個過程中學(xué)會的不只是代碼開發(fā)，還有更多的落地思想實踐在這里面體現(xiàn)出來。也能為你以后開發(fā)這樣的一個項目或者在面試過程中，一些實際復(fù)雜場景問題的設(shè)計思路，打下不錯的基礎(chǔ)。

當前文章：怎么說服領(lǐng)導(dǎo)，能讓我用DDD架構(gòu)？
URL分享：http://uogjgqi.cn/article/djcegeo.html