【吐血推荐】领域驱动设计学习输出
一、Hello DDD
剛開(kāi)始接觸學(xué)習(xí)「DDD - 領(lǐng)域驅(qū)動(dòng)」的時(shí)候，我被各種新穎的概念所吸引：「領(lǐng)域」、「領(lǐng)域驅(qū)動(dòng)」、「子域」、「聚合」、「聚合根」、「值對(duì)象」、「通用語(yǔ)言」.....總之一大堆有關(guān)的、無(wú)關(guān)的概念從我的腦海經(jīng)過(guò)，其中不乏讓我陷入思考的地方，我原以為我會(huì)很開(kāi)心地?“享用”?這些新知識(shí)帶給我的營(yíng)養(yǎng)（參照下圖）
可事實(shí)上，我為學(xué)習(xí)「DDD - 領(lǐng)域驅(qū)動(dòng)」付出了很多的精力，我嘗試用「DDD CRUD」、「DDD vs CRUD」、「Domain-Driven Design」、「DDD CQRS」、「領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)」等等一系列的關(guān)鍵字搜集我想要的資料（翻遍了 Google 前排的所有文章&手動(dòng)感謝谷歌讓我能獲得一些精彩的文章），可似乎都不太近人意，一方面這個(gè)「新概念」我對(duì)它的困惑太多了，另一方面真正「落地」并實(shí)踐起來(lái)的經(jīng)驗(yàn)有很少是可以直接借鑒的，再結(jié)合一些實(shí)際的場(chǎng)景（沒(méi)有人解答），我感到更加困惑。
傳統(tǒng)開(kāi)發(fā)面臨的問(wèn)題
我們先來(lái)討論一下傳統(tǒng)開(kāi)發(fā)面臨的一些問(wèn)題吧，就先從傳統(tǒng)開(kāi)發(fā)中被廣泛應(yīng)用于 Web 開(kāi)發(fā)的傳統(tǒng)三層框架：「MVC」 開(kāi)始說(shuō)起吧。
- 圖片來(lái)源：https://draveness.me/mvx
傳統(tǒng)的「MVC」模型把框架分成了三層：顯示層、控制層、模型層，而傳統(tǒng)的模型層又被拆分成了業(yè)務(wù)層（Service）和數(shù)據(jù)訪問(wèn)層（DAO,Data Access Object）。
顯示層負(fù)責(zé)顯示用戶界面、控制層負(fù)責(zé)處理業(yè)務(wù)邏輯、而模型則負(fù)責(zé)與數(shù)據(jù)庫(kù)通信，對(duì)數(shù)據(jù)進(jìn)行持久化的操作。這樣的結(jié)構(gòu)不僅結(jié)構(gòu)松散，而且各個(gè)模塊職責(zé)分離，有什么問(wèn)題呢？
讓我們來(lái)看一個(gè)實(shí)際的例子吧。
假設(shè)我們做了一個(gè)會(huì)議室預(yù)定系統(tǒng)，我們的一個(gè)設(shè)備壞了。我們需要通知預(yù)定這個(gè)會(huì)議室的所有人，于是我們需要發(fā)郵件，偽代碼如下：
@Service public class EquipmentServiceImpl implements EquipmentService {@Autowired private EmailService emailService;@Autowired private EquipmentRepository equipmentRepository;public void setEquipmentBroken(Long id) {Equipment equipment = equipmentRepository.findById(id);equipment.setStatus(Equipment.StatusEnum.BROKEN);emailService.sendEmail();} }問(wèn)題來(lái)了，如果我們后來(lái)發(fā)現(xiàn)設(shè)備壞了并且需要更改可用庫(kù)存的數(shù)量，這時(shí)候我們是不是要在這里加入?InventoryService?庫(kù)存服務(wù)的代碼呢？后來(lái)如果經(jīng)理說(shuō)設(shè)備壞了應(yīng)該通知他才對(duì)啊，所以我們要不要加入?emailService.sendEmailTo(Manager)?這樣的代碼呢？
就算不考慮職責(zé)單一原則和關(guān)注分離原則，程序員也會(huì)瘋掉的，這樣做?Service 太重了，并且糟糕的是它可能還不止考慮這些，還有權(quán)限、事務(wù)等等一系列的事情等著 Service 層去做，如此產(chǎn)生了大量的依賴和循環(huán)依賴，當(dāng)業(yè)務(wù)復(fù)雜度上升時(shí)，直接導(dǎo)致了服務(wù)層所含的代碼過(guò)于龐大和復(fù)雜、測(cè)試成本直線上升，并且各個(gè)?Service 的邏輯散落在各處，維護(hù)的成本也非常大。
我相信很多公司正在經(jīng)歷這樣的事情，并且問(wèn)題還遠(yuǎn)不止于此。
最近我就經(jīng)歷過(guò)另一種問(wèn)題。作為實(shí)習(xí)生剛?cè)牍镜奈医拥疆a(chǎn)品了一個(gè)需求，雖然有正規(guī)的需求文檔可以供我閱讀，但對(duì)于業(yè)務(wù)還不熟悉的我讀起來(lái)就感覺(jué)是：摁，我想要這個(gè)頁(yè)面這樣。
當(dāng)產(chǎn)品經(jīng)歷耐心的過(guò)來(lái)給我解釋的時(shí)候，我仍然感到無(wú)奈，因?yàn)樗M可能詳細(xì)地在描述他想要在哪一個(gè)頁(yè)面的哪一個(gè)地方加上什么東西的同時(shí)，我看著眼前屏幕上的一堆模型和代碼，感到無(wú)從下手，只能找來(lái)大佬幫忙充當(dāng)一下 “翻譯”。
必須承認(rèn)自己對(duì)業(yè)務(wù)的生疏是主要的原因，但根本原因還是：開(kāi)發(fā)與產(chǎn)品之間的「溝通」不能保持一致，雙方對(duì)于同一事物的「表達(dá)和理解」有很大的區(qū)別。產(chǎn)品看到的是實(shí)際的「業(yè)務(wù)場(chǎng)景」，而開(kāi)發(fā)則更關(guān)注背后的「實(shí)現(xiàn)邏輯」。
CRUD 的各種問(wèn)題
上面或許有說(shuō)得不對(duì)的地方，但這樣的現(xiàn)象確實(shí)的存在。（例如我審視了一下我之前寫(xiě)過(guò)的代碼，突然感慨幸好自己之前都是獨(dú)立開(kāi)發(fā)且功能簡(jiǎn)單，嘻嘻嘻）
另一個(gè)想要討論的問(wèn)題是關(guān)于后端開(kāi)發(fā)者常常拿來(lái)自嘲的「CRUD」。經(jīng)常有開(kāi)發(fā)人員苦著臉說(shuō)：每天除了寫(xiě)「BUG」，就一直在寫(xiě)「CRUD」代碼，沒(méi)有很大長(zhǎng)進(jìn)。當(dāng)然這只是一種自嘲，但可能寫(xiě)「BUG」是真的，也可能沒(méi)有長(zhǎng)進(jìn)是真的，當(dāng)然兩個(gè)都可能都是真的。
「CRUD」?其實(shí)對(duì)應(yīng)的是數(shù)據(jù)庫(kù)中的增刪改查的操作。現(xiàn)實(shí)的情況中，只有極少有企業(yè)不用到數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)就像是現(xiàn)代軟件開(kāi)發(fā)的一劑靈丹妙藥，不僅提供可靠、快速、大容量的存儲(chǔ)服務(wù)，還支持強(qiáng)大的事務(wù)管理機(jī)制，滿足了大部分場(chǎng)景中對(duì)數(shù)據(jù)的一致性需求。
數(shù)據(jù)庫(kù)如此的強(qiáng)大，以至于我們從接觸軟件開(kāi)發(fā)開(kāi)始就一直使用「CRUD」的模式進(jìn)行開(kāi)發(fā)。我們的「潛意識(shí)」中就形成了「以數(shù)據(jù)為中心」的開(kāi)發(fā)模式，這沒(méi)有什么不好，并且大多數(shù)情況下是適用的，這里只是討論：「CRUD」有什么問(wèn)題？
問(wèn)題一：面向?qū)ο蠛蛿?shù)據(jù)庫(kù)天然阻抗
面向?qū)ο缶幊痰恼Z(yǔ)言和數(shù)據(jù)庫(kù)都是我們幾乎“最熟悉”的東西了，我們甚至使用他們編織出了絕大多數(shù)復(fù)雜多樣的網(wǎng)絡(luò)應(yīng)用，為什么說(shuō)它們之間存在著天然阻抗？
當(dāng)然我覺(jué)得這里有一點(diǎn)「強(qiáng)行找不同」的味道，但也不失為一種思考和討論。并且我覺(jué)得還是有點(diǎn)道理的。
A1：對(duì)象和關(guān)系數(shù)據(jù)庫(kù)累贅轉(zhuǎn)換
在一個(gè)面向?qū)ο蟮南到y(tǒng)中，對(duì)象是數(shù)據(jù)的承載方式，每一個(gè) DAO 對(duì)象都對(duì)應(yīng)著關(guān)系數(shù)據(jù)庫(kù)中的一條數(shù)據(jù)。
但通常視圖層只顯示完整實(shí)體對(duì)象的一小部分?jǐn)?shù)據(jù)，那么其余的「無(wú)關(guān)數(shù)據(jù)」你準(zhǔn)備怎么處理呢？
- 是否要把對(duì)象中包含的「所有數(shù)據(jù)」一起返回給視圖層？
- 是否需要?jiǎng)?chuàng)建一個(gè)新的專用的「數(shù)據(jù)傳輸對(duì)象」？
- 或者你想直接把「無(wú)關(guān)數(shù)據(jù)」字段設(shè)置成?null？
顯然，在絕大多數(shù)應(yīng)用中都采取了第二種方案，于是我們看到各種冗余、繁多的「?jìng)鬏攲訉?duì)象」，隨著時(shí)間的推移，系統(tǒng)中堆積的「?jìng)鬏攲訉?duì)象」越來(lái)越多，不僅增加了系統(tǒng)的「復(fù)雜度」，而且還降低了我們的「開(kāi)發(fā)效率」。我猜這也是人們說(shuō) Java 復(fù)雜的一方面原因吧。
更重要的是，萬(wàn)一有一個(gè)字段發(fā)生變化，更改量就很大。（當(dāng)然這也有解決方案）
A2：繼承關(guān)系的尷尬實(shí)現(xiàn)
繼承是面向?qū)ο蟮囊粋€(gè)重要特性，而關(guān)系數(shù)據(jù)庫(kù)卻難以復(fù)現(xiàn)對(duì)象世界中的繼承關(guān)系。
我們來(lái)試著還原一下上面的繼承關(guān)系吧。
如果我們按照把?Student?和?Professor?建成兩張表，問(wèn)題就是：關(guān)系數(shù)據(jù)庫(kù)分割了兩個(gè)對(duì)象的共性?Person。從語(yǔ)義上說(shuō)：也就是將一個(gè)對(duì)象分割成兩個(gè)部分了；而且當(dāng)你要獲取這個(gè)對(duì)象時(shí)，需要兩次Select。同樣道理增刪改查都要兩次。
如果我們把?Student?和?Professor?合并成一張表，問(wèn)題就是：會(huì)產(chǎn)生許多空白字段。這很容易理解。
這些都反映了面向?qū)ο蠛完P(guān)系數(shù)據(jù)庫(kù)天然不匹配，只能一方作出妥協(xié)，并且大部分情況是面相對(duì)象作出妥協(xié)。
A3：類的復(fù)雜關(guān)系實(shí)現(xiàn)
當(dāng)我們需要?jiǎng)?chuàng)建一個(gè)部門（Department），而一個(gè)部門將擁有多個(gè)教授（Professor）這樣一個(gè)模型的時(shí)候，我們發(fā)現(xiàn)面向?qū)ο蠛完P(guān)系數(shù)據(jù)庫(kù)「表達(dá)方式」的是兩種不同的形式：
- 面向?qū)ο?#xff1a;
我是一個(gè)部門，在我里面有很多的教授； - 關(guān)系數(shù)據(jù)庫(kù)，由于外鍵會(huì)在 Professor 上：
我是一個(gè)教授，我屬于那個(gè)部門。
問(wèn)題二：是一種數(shù)據(jù)模型，與業(yè)務(wù)脫節(jié)
沒(méi)有一個(gè)「真實(shí)的人」會(huì)在支付一筆訂單的時(shí)候說(shuō)：（大概意思..）
=> 先通過(guò)我這個(gè)訂單的編號(hào)找到原始在系統(tǒng)上的記錄；
=> 把支付金額改成我實(shí)際支付的金額；
=> 把這個(gè)訂單的狀態(tài)修改成已支付
=> ........
而一個(gè)「真實(shí)的人」會(huì)直接說(shuō)：我為這筆訂單付了xxx錢。
關(guān)系型數(shù)據(jù)庫(kù)（Relational Database）的核心實(shí)體就是數(shù)據(jù)表，核心操作就是在定義好的數(shù)據(jù)表上的「CRUD」操作。這套東西實(shí)在是太好用了，也太深入人心了，以至于你能在好多地方都能看到這種將關(guān)系模式直接用作業(yè)務(wù)模式的系統(tǒng)：
比如我之前寫(xiě)的所有東西。（就拿我寫(xiě)的個(gè)人博客為例吧：https://github.com/wmyskxz/MyBlog）
問(wèn)題出在：我的「Entity層」只是數(shù)據(jù)庫(kù)表結(jié)構(gòu)的一種映射用于承載數(shù)據(jù)，我的「DAO層」只是封裝了對(duì)「Entity層」的增刪改查，我的「Controller層」只是簡(jiǎn)單的把地址和對(duì)應(yīng)「Service層」的對(duì)應(yīng)方法做了關(guān)聯(lián)返回結(jié)果給「視圖層」，而我的「Service層」則大部分工作也只是在做一些「查詢」、「拼接數(shù)據(jù)」的工作，這樣的系統(tǒng)是聲稱套上了業(yè)務(wù)的外衣，而實(shí)則只是「皇帝的新衣」，幾乎無(wú)法保證業(yè)務(wù)邏輯的正確性、完整性。
我還記得朋友問(wèn)過(guò)我一個(gè)問(wèn)題，大意就是有一部分的系統(tǒng)其實(shí)只是對(duì)數(shù)據(jù)庫(kù)的簡(jiǎn)單封裝，感覺(jué)就像是系統(tǒng)只是數(shù)據(jù)庫(kù)的「簡(jiǎn)單代理」一樣。我一開(kāi)始有點(diǎn)兒感同身受，但現(xiàn)在回過(guò)頭想，只是我們當(dāng)時(shí)做的東西太簡(jiǎn)單了而已。簡(jiǎn)單的系統(tǒng)也就是對(duì)數(shù)據(jù)庫(kù)的「CRUD」。
但這還不是重點(diǎn)，重點(diǎn)是大部分的「CRUD工程師」對(duì)「業(yè)務(wù)理解」出了問(wèn)題。
讓我們拿國(guó)際象棋舉個(gè)例子：
- 圖片引自：https://zhuanlan.zhihu.com/p/25442175
作為一枚「CRUD工程師」，在完成了左邊部分的數(shù)據(jù)庫(kù)設(shè)計(jì)和右邊的數(shù)據(jù)展現(xiàn)之后，往往就認(rèn)為已經(jīng)萬(wàn)事大吉了。但這樣的產(chǎn)品交付之后，對(duì)現(xiàn)實(shí)中使用它的用戶提出了很多的潛在要求。「CRUD工程師」從來(lái)不會(huì)提示你這些潛在需求，誰(shuí)會(huì)對(duì)自己并不知道的事情加以說(shuō)明呢？
簡(jiǎn)而言之，這樣的一個(gè)國(guó)際象棋程序，自身對(duì)國(guó)際象棋規(guī)則完全是一竅不通的。就是拿出個(gè)表格給你，隨你填成啥樣。在這件事情上，完全指望使用者不犯錯(cuò)，這是何等的心大！
- 圖片引自：https://zhuanlan.zhihu.com/p/25442175
于是，這個(gè)國(guó)際象棋程序完全有可能出現(xiàn)?Bad case?的這種詭異情況：黑色騎士（knight）走出一個(gè)華麗的斜線，和其中一個(gè)白色兵（pawn）共處一室（什么鬼？！）「國(guó)際象棋填表系統(tǒng)」并不會(huì)阻止你這樣做，因?yàn)樗](méi)有正確與錯(cuò)誤之分。
這時(shí)候，「CRUD工程師」被客戶、老板抓出來(lái)收拾殘局了。經(jīng)過(guò)一番調(diào)研，原來(lái)客戶是想把黑色騎士走到 6d，并吃掉（capture）另一個(gè)白色兵。“產(chǎn)品已經(jīng)夠簡(jiǎn)單的了，客戶怎么都這么蠢？”「CRUD工程師」嘀咕道，“哎，這工作坑真是多啊”。
- 原片段摘自：https://zhuanlan.zhihu.com/p/25442175
問(wèn)題三：CRUD 缺少意圖（intent）
事實(shí)上我們可以使用「CRUD」架構(gòu)很好的服務(wù)絕大多數(shù)的應(yīng)用。但是正如上面提到的問(wèn)題所說(shuō)的那樣，當(dāng)系統(tǒng)的「復(fù)雜度」上升的時(shí)候，「CRUD」可能會(huì)缺少一件事：意圖（intent）。
例如：
我們想要改變一個(gè) Customer 的地址，在「CRUD」體系中，我們只需要發(fā)出更新語(yǔ)句就能實(shí)現(xiàn)。但是我們無(wú)法弄清楚這種變化是由不正確的操作引起的，還是客戶真的轉(zhuǎn)移到了另一個(gè)城市。也許我們有一個(gè)業(yè)務(wù)場(chǎng)景，需要再重新定位時(shí)觸發(fā)對(duì)外部系統(tǒng)的通知。在這種情況下，「CRUD」顯得有所缺失。
問(wèn)題四：實(shí)施協(xié)作“困難”
在大多數(shù)的「CRUD」應(yīng)用中，最新的更改將覆蓋其他用戶并行執(zhí)行的其他更改。也就是說(shuō)如果一個(gè)團(tuán)隊(duì)中的兩個(gè)人同時(shí)對(duì)同一個(gè)文件的同一行進(jìn)行修改，那么合并代碼的時(shí)候就會(huì)產(chǎn)生「沖突」。
在上面我們論述了在傳統(tǒng)「CRUD」這樣的矛盾是如何產(chǎn)生的：散落在各處分散的邏輯代碼。
問(wèn)題五：被人詬病的「U」
「CRUD」中的「U」指的是「更新」操作。通常在我們的系統(tǒng)中「U」作為一種通用的方法可以更新資源的任何字段，然后使用新版本覆蓋掉舊版本。
并且現(xiàn)在由于「REST」的流行，大多數(shù)的「API」都是圍繞「資源模型」來(lái)進(jìn)行「CRUD」操作的，這樣做不僅確實(shí)極大地方便了開(kāi)發(fā)人員的工作，并且借由「HTTP動(dòng)詞」和「資源URI」結(jié)合起來(lái)有很好的可讀性。
但這有什么問(wèn)題呢？
我們考慮一個(gè)簡(jiǎn)單的「銀行賬戶」資源的問(wèn)題。當(dāng)我們需要把賬戶的余額更新為想要的數(shù)量的時(shí)候，我們應(yīng)該允許客戶端直接調(diào)用更新方法嗎？任何余額調(diào)整的動(dòng)作都應(yīng)該作為某種類型的交易事務(wù)被記錄下來(lái)才對(duì)，例如「充值」、「取錢」，還是「轉(zhuǎn)賬」？另外賬戶是否存在？可能變更嗎？等等一系列問(wèn)題都可能使你的通用「U」變得臃腫難以維護(hù)。
基于上述的多種多樣的「場(chǎng)景」，我們的通用「U」方法被推向了尷尬的境地。事實(shí)上這可能屬于設(shè)計(jì)的問(wèn)題，不知道一般的公司中是如何解決的，至少在我之前寫(xiě)的代碼中，我是這樣實(shí)現(xiàn)的。（并且可能覺(jué)得沒(méi)有什么問(wèn)題）
另外也有的人說(shuō)「CRUD」限制了描述業(yè)務(wù)的語(yǔ)言的問(wèn)題。因?yàn)樵鰟h改查只有四個(gè)動(dòng)詞，而我們實(shí)際的業(yè)務(wù)場(chǎng)景可能更加復(fù)雜。
問(wèn)題六：提供變更歷史記錄的操作很復(fù)雜
還有一個(gè)問(wèn)題：「CRUD」會(huì)丟失應(yīng)用程序的歷史記錄。例如，如果用戶在一段時(shí)間內(nèi)多次變更記錄，我們則無(wú)法再跟蹤單個(gè)更改。更糟糕的是，甚至無(wú)法確定該條目是否曾經(jīng)被改變過(guò)。
當(dāng)然，這可以通過(guò)為最后更新的時(shí)間戳添加字段來(lái)處理，但這只會(huì)幫助我們能夠獲得最新的更新。如果你對(duì)整個(gè)歷史感興趣，事情就會(huì)變得復(fù)雜：你必須從一開(kāi)始就額外引入一組字段or一張新表。
這里的問(wèn)題是：由于你不知道將來(lái)會(huì)詢問(wèn)哪些關(guān)于你數(shù)據(jù)的問(wèn)題，因此你無(wú)法針對(duì)相應(yīng)的情況對(duì)表做出優(yōu)化。因?yàn)槟闶占嗷蛘咛俚臄?shù)據(jù)，似乎都存在一定問(wèn)題。
總結(jié)
現(xiàn)在早已經(jīng)不再是 PC Web 的時(shí)代了，原生 APP、移動(dòng) Web 等等多種客戶端技術(shù)在近幾年爆發(fā)（IOS、Android、JavaScript、...），青出于藍(lán)而勝于藍(lán)。原先「MVC」中的視圖（Web頁(yè)面）渲染工作，面臨被新技術(shù)的完全替代。「CRUD工程師」手中的系統(tǒng)們，面臨向「SOA」的轉(zhuǎn)型。
夜深人靜，四下無(wú)人的時(shí)候，「CRUD工程師」再次陷入深深的困惑：一邊是臃腫不堪的模型和控制器層，另一邊是逐漸收縮和服務(wù)化的視圖層，難道建表、寫(xiě)表、讀表就要成為我的唯一主題了嗎？
「CRUD工程師」認(rèn)為自己沒(méi)有創(chuàng)造任何東西，他們只是數(shù)據(jù)庫(kù)表的搬運(yùn)工。而如果不是「CRUD」，業(yè)務(wù)系統(tǒng)后端工程師的價(jià)值在哪里？
理解并抽象出業(yè)務(wù)邏輯，建立滿足需求的業(yè)務(wù)模型，以此設(shè)計(jì)實(shí)現(xiàn)出可靠的系統(tǒng)，并有效地控制復(fù)雜性。這才是大部分業(yè)務(wù)系統(tǒng)后端工程師的工作重點(diǎn)，也是解決他們工作中遇到的問(wèn)題和難點(diǎn)的關(guān)鍵。
- 觀點(diǎn)來(lái)自：https://zhuanlan.zhihu.com/p/25442175
愛(ài)因斯坦說(shuō)：“如果給我 1 個(gè)小時(shí)解答一道決定我生死的問(wèn)題，我會(huì)花 55 分鐘來(lái)弄清楚這道題到底是在問(wèn)什么。一旦清楚了它到底在問(wèn)什么，剩下的 5 分鐘足夠回答這個(gè)問(wèn)題。”
雖然目前為止我們還不太了解「DDD」是如何幫助我們解決傳統(tǒng)開(kāi)發(fā)中的各種問(wèn)題，但是聽(tīng)說(shuō)「DDD - 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)」似乎是能夠用來(lái)設(shè)計(jì)和實(shí)現(xiàn)業(yè)務(wù)邏輯的一劑良藥。
所以「Hello - DDD」。
二、DDD 是什么？
「DDD」的全稱是「Domain-driven Design」，即「領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)」。是由「Eric Evans」最早提出的綜合軟件系統(tǒng)分析和設(shè)計(jì)的面向?qū)ο蠼７椒?#xff0c;如今已經(jīng)發(fā)展為一種針對(duì)大型復(fù)雜系統(tǒng)的領(lǐng)域建模與分析方法。
它完全改變了傳統(tǒng)軟件開(kāi)發(fā)工程師針對(duì)數(shù)據(jù)庫(kù)進(jìn)行的建模方法，從而將要解決的業(yè)務(wù)概念和業(yè)務(wù)規(guī)則轉(zhuǎn)換為軟件系統(tǒng)中的類型以及類型的屬性與行為，通過(guò)合理運(yùn)用面向?qū)ο蟮姆庋b、繼承、多態(tài)等設(shè)計(jì)要素，降低或隱藏整個(gè)系統(tǒng)的業(yè)務(wù)復(fù)雜性，并使得系統(tǒng)具有更好的擴(kuò)展性，應(yīng)對(duì)紛繁多變的現(xiàn)實(shí)業(yè)務(wù)問(wèn)題。
- 總結(jié)：?目前為止，您只需要知道「DDD」是一種致力于降低或隱藏整個(gè)系統(tǒng)業(yè)務(wù)復(fù)雜性，讓系統(tǒng)具有更好擴(kuò)展，應(yīng)對(duì)紛雜繁多的現(xiàn)實(shí)也問(wèn)題的架構(gòu)方法就行了。
DDD 簡(jiǎn)史
- 圖片引自：https://www.jianshu.com/p/e1b32a5ee91c
領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)這個(gè)概念出現(xiàn)在 2003 年，那個(gè)時(shí)候的軟件還處在從 CS 到 BS 轉(zhuǎn)換的時(shí)期，敏捷宣言也才發(fā)表 2 年。但是「Eric Evans」作為在企業(yè)級(jí)應(yīng)用工作多年的技術(shù)顧問(wèn)，敏銳的發(fā)現(xiàn)了在軟件開(kāi)發(fā)業(yè)界內(nèi)（尤其是企業(yè)級(jí)應(yīng)用）開(kāi)始涌現(xiàn)的一股思潮，他把這股思潮稱為領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)，同時(shí)還出版了一本書(shū)，在書(shū)中分享了自己在設(shè)計(jì)軟件項(xiàng)目時(shí)采用的建模方法，并為設(shè)計(jì)決策者提供了一個(gè)框架。
但是從那以后「DDD」并沒(méi)有和「敏捷」一樣變得更加流行，如果要問(wèn)原因，我覺(jué)得一方面是這套方法里面有很多的新名詞新概念，比如說(shuō)「聚合」，「限界上下文」，「值對(duì)象」等等，要理解這些抽象概念本身就比較困難，所以學(xué)習(xí)和應(yīng)用「DDD」的曲線是非常陡峭的。另一方面，做為當(dāng)時(shí)唯一的“官方教材”《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》，閱讀這本書(shū)是一個(gè)非常痛苦的過(guò)程，在內(nèi)容組織上經(jīng)常會(huì)出現(xiàn)跳躍，所以很多人都是剛讀了幾頁(yè)就放下了。
雖然入門門檻有些高，但是對(duì)于喜歡智力挑戰(zhàn)的軟件工程師們來(lái)說(shuō)，這就是一個(gè)難度稍為有一點(diǎn)高的玩具，所以在小范圍群體內(nèi)，逐漸有一批人開(kāi)始能夠掌控這個(gè)玩具，并且可以用它來(lái)指導(dǎo)設(shè)計(jì)能夠控制業(yè)務(wù)復(fù)雜性的軟件應(yīng)用出來(lái)了。雖然那時(shí)候大部分的軟件應(yīng)用都是單體的，但是使用「DDD」依然可以設(shè)計(jì)出來(lái)容易維護(hù)而且快速響應(yīng)需求變化的單體應(yīng)用出來(lái)。
到了 2013 年，隨著各種分布式的基礎(chǔ)設(shè)施逐漸成熟，而「SOA架構(gòu)」應(yīng)用在實(shí)踐中又不是那么順利，Martin Fowler 和 James Lewis 把當(dāng)時(shí)出現(xiàn)的一種新型分布式架構(gòu)風(fēng)潮總結(jié)成微服務(wù)架構(gòu)。
然后微服務(wù)這股風(fēng)就呼呼的吹了起來(lái)，這時(shí)候軟件工程師們發(fā)現(xiàn)一個(gè)問(wèn)題，就是雖然指導(dǎo)微服務(wù)架構(gòu)的應(yīng)用具有什么特征，但是如何把原來(lái)的大單體拆分成微服務(wù)是完全不知道怎么做了。
然后熟悉「DDD」方法的工程師發(fā)現(xiàn)，由于「DDD」可以有效的從業(yè)務(wù)視角對(duì)軟件系統(tǒng)進(jìn)行拆解，并且「DDD」特別契合微服務(wù)的一個(gè)特征：圍繞業(yè)務(wù)能力構(gòu)建。所以用「DDD」拆分出來(lái)的微服務(wù)是比較合理的而且能夠?qū)崿F(xiàn)高內(nèi)聚低耦合，這樣接著微服務(wù)「DDD」迎來(lái)了它的第二春。
DDD 思辨
從計(jì)算機(jī)發(fā)明以來(lái)，人類用過(guò)表達(dá)世界變化的詞有：電子化，信息化，數(shù)字化。這些詞里面都有一個(gè) “化” 字，代表著轉(zhuǎn)變，而這些轉(zhuǎn)變就是人類在逐漸的把原來(lái)在物理世界中的一個(gè)個(gè)概念一個(gè)個(gè)工作，遷移到虛擬的計(jì)算機(jī)世界。
但是在轉(zhuǎn)變的過(guò)程中，由于兩個(gè)世界的底層邏輯以及底層語(yǔ)言不一致，就必須要有一個(gè)翻譯和設(shè)計(jì)的過(guò)程。這個(gè)翻譯過(guò)程從軟件誕生的第一天起就天然存在，而由于有了這個(gè)翻譯過(guò)程，業(yè)務(wù)和開(kāi)發(fā)之間才總是想兩個(gè)對(duì)立的階級(jí)一樣，覺(jué)得對(duì)方是難以溝通的。
于是乎有些軟件工程界的大牛就開(kāi)始思考，能不能有一種方式來(lái)減輕這個(gè)翻譯過(guò)程呢。然后就發(fā)明了「面向?qū)ο笳Z(yǔ)言」，開(kāi)始嘗試讓計(jì)算機(jī)世界有物理世界的對(duì)象概念。面向?qū)ο筮€不夠，這就有了「DDD」，「DDD」定義了一些基本概念，然后嘗試讓業(yè)務(wù)和開(kāi)發(fā)都能夠理解這些概念名詞，然后讓「領(lǐng)域?qū)＜摇?#xff08;這里你可以理解為熟悉業(yè)務(wù)的人）使用這些概念名詞來(lái)描述業(yè)務(wù)，而由于使用了規(guī)定的概念名詞，開(kāi)發(fā)就可以很好的理解領(lǐng)域業(yè)務(wù)，并能夠按照領(lǐng)域業(yè)務(wù)設(shè)計(jì)的方式進(jìn)行軟件實(shí)現(xiàn)。
這就是DDD的初衷：讓業(yè)務(wù)架構(gòu)綁定系統(tǒng)架構(gòu)。
后來(lái)發(fā)現(xiàn)這個(gè)方法不僅僅可以做好翻譯，還可以幫助業(yè)務(wù)劃分領(lǐng)域邊界，可以明確哪個(gè)領(lǐng)域是自己的核心價(jià)值所在，以后應(yīng)該重點(diǎn)發(fā)展哪個(gè)領(lǐng)域。甚至可以作為組織進(jìn)行戰(zhàn)略規(guī)劃的參考。而能夠做到這點(diǎn)，其實(shí)背后的原因是物理世界和虛擬世界的融合。
三、為什么使用 DDD？
DDD 幫助解決微服務(wù)拆分困境
上面介紹了使用DDD可以做到綁定業(yè)務(wù)架構(gòu)和系統(tǒng)架構(gòu)，這種綁定對(duì)于微服務(wù)來(lái)說(shuō)有什么關(guān)系呢。所謂的微服務(wù)拆分困難，其實(shí)根本原因是不知道邊界在什么地方。而使用DDD對(duì)業(yè)務(wù)分析的時(shí)候，首先會(huì)使用「聚合」這個(gè)概念把關(guān)聯(lián)性強(qiáng)的業(yè)務(wù)概念劃分在一個(gè)邊界下，并限定「聚合」和「聚合」之間只能通過(guò)「聚合根」來(lái)訪問(wèn)，這是第一層邊界。
然后在「聚合」基礎(chǔ)之上根據(jù)「業(yè)務(wù)相關(guān)性」、「業(yè)務(wù)變化頻率」、「組織結(jié)構(gòu)」等等約束條件來(lái)定義「限界上下文」，這是第二層邊界。有了這兩層邊界作為約束和限制，微服務(wù)的邊界也就清晰了，拆分微服務(wù)也就不再困難了。
DDD 幫助應(yīng)對(duì)系統(tǒng)復(fù)雜性
解決復(fù)雜和大規(guī)模軟件的武器可以被粗略地歸為三類：「抽象」、「分治」和「知識(shí)」。
-
分治：?把問(wèn)題空間分割為規(guī)模更小且易于處理的若干子問(wèn)題。分割后的問(wèn)題需要足夠小，以便一個(gè)人單槍匹馬就能夠解決他們；其次，必須考慮如何將分割后的各個(gè)部分裝配為整體。分割得越合理越易于理解，在裝配成整體時(shí)，所需跟蹤的細(xì)節(jié)也就越少。即更容易設(shè)計(jì)各部分的協(xié)作方式。評(píng)判什么是分治得好，即高內(nèi)聚低耦合。
-
抽象：?使用抽象能夠精簡(jiǎn)問(wèn)題空間，而且問(wèn)題越小越容易理解。舉個(gè)例子，從北京到上海出差，可以先理解為使用交通工具前往，但不需要一開(kāi)始就想清楚到底是高鐵還是飛機(jī)，以及乘坐它們需要注意什么。
-
知識(shí)：?顧名思義，「DDD」可以認(rèn)為是知識(shí)的一種。
「DDD」提供了這樣的知識(shí)手段，讓我們知道如何抽象出「限界上下文」以及如何去「分治」。
- 圖片來(lái)源：https://servicecomb.apache.org/cn/docs/crm-part-I/
另外一個(gè)感受就是我們可以使用「領(lǐng)域事件」來(lái)應(yīng)對(duì)多樣的變化。參考上面提到發(fā)郵件的例子，我們可以把它改造成這樣：
public void setEquipmentBroken(Long id) {Equipment equipment = equipmentRepository.findById(id);equipment.broken();eventBus.publish(new EquipmentBrokenEvent(equipment.id)); }這樣，通知會(huì)議室預(yù)訂者的模塊就會(huì)去通知相應(yīng)的人員，而不用我們自己操心了。
更為重要的是，「DDD」架構(gòu)區(qū)別于傳統(tǒng)的方式。
- 圖片引自：https://blog.pragmatists.com/domain-driven-design-vs-anemic-model-how-do-they-differ-ffdee9371a86
我們需要先了解一個(gè)概念：「貧血模型」。也就是只有屬性的類，貧血的意思就是沒(méi)有行為，像木乃伊一樣。這種模型唯一的作用就是將一些 ORM 映射到對(duì)應(yīng)的數(shù)據(jù)庫(kù)上，而我們的「服務(wù)層」通過(guò)「DAO層」加載這些「貧血模型」進(jìn)行一些拼接之類的操作，功能越復(fù)雜，這種操作就越頻繁，這是我們的軟件復(fù)雜度上升的直接原因。
而「DDD」則把大多數(shù)的業(yè)務(wù)邏輯都包含在了「聚合」、「實(shí)體」、「值對(duì)象」里面，簡(jiǎn)單理解也就是實(shí)現(xiàn)了對(duì)象自治，把之前暴露出來(lái)的一些業(yè)務(wù)操作隱藏進(jìn)了「域」之中。每個(gè)不同的區(qū)域之間只能通過(guò)對(duì)外暴露的統(tǒng)一的聚合根來(lái)訪問(wèn)，這樣就做了收權(quán)的操作，這樣數(shù)據(jù)的定義和更改的地方就聚集在了一處，很好的解決了復(fù)雜度的問(wèn)題。
DDD 幫助統(tǒng)一語(yǔ)言
在UML作為建模主流的時(shí)代，軟件設(shè)計(jì)被明確分為面向?qū)ο蠓治?#xff08;OOA），面向?qū)ο笤O(shè)計(jì)（OOD）和面向?qū)ο缶幋a（OOP）階段。實(shí)際操作中OOD的工作往往被OOA和OOP各自承擔(dān)一部分，并同時(shí)存在分析模型和設(shè)計(jì)模型兩個(gè)割裂的模型。
而領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的核心是建立統(tǒng)一的領(lǐng)域模型。領(lǐng)域模型在軟件架構(gòu)中處于核心地位，軟件開(kāi)發(fā)過(guò)程中，必須以建立領(lǐng)域模型為中心，以保障領(lǐng)域模型的忠實(shí)體現(xiàn)。
- 圖片來(lái)源：http://kaelzhang81.github.io/2017/10/20/DDD%E4%B9%8B-%E9%81%93%E6%9C%AF%E5%99%A8/
簡(jiǎn)單理解起來(lái)的話，也就是把業(yè)務(wù)人員和開(kāi)發(fā)人員的語(yǔ)言統(tǒng)一起來(lái)，用代碼來(lái)感受一下大概就是：
userService.love(Jack, Rose) => Jack.love(Rose) companyService.hire(company,employee) => Company.hire(employee)四、領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)過(guò)程
領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)強(qiáng)調(diào)領(lǐng)域模型的重要性，并通過(guò)模型驅(qū)動(dòng)設(shè)計(jì)來(lái)保障領(lǐng)域模型與程序設(shè)計(jì)的一致。從業(yè)務(wù)需求中提煉出統(tǒng)一語(yǔ)言（Ubiquitous Language），再基于統(tǒng)一語(yǔ)言建立領(lǐng)域模型；這個(gè)領(lǐng)域模型會(huì)指導(dǎo)著程序設(shè)計(jì)以及編碼實(shí)現(xiàn)；最后，又通過(guò)重構(gòu)來(lái)發(fā)現(xiàn)隱式概念，并運(yùn)用設(shè)計(jì)模式改進(jìn)設(shè)計(jì)與開(kāi)發(fā)質(zhì)量。這個(gè)過(guò)程如下圖所示：
- 圖片來(lái)源：http://zhangyi.xyz/overview-of-ddd/
這個(gè)過(guò)程是一個(gè)覆蓋軟件全生命周期的設(shè)計(jì)閉環(huán)，每個(gè)環(huán)節(jié)的輸出都可以作為下一個(gè)環(huán)節(jié)的輸入，而在其中扮演重要指導(dǎo)作用的則是“領(lǐng)域模型”。這個(gè)設(shè)計(jì)閉環(huán)是一個(gè)螺旋上升的迭代設(shè)計(jì)過(guò)程，領(lǐng)域模型會(huì)在這個(gè)迭代過(guò)程中逐漸演進(jìn)，在保證模型完整性與正確性的同時(shí)，具有新鮮的活力，使得領(lǐng)域模型能夠始終如一的貫穿領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)過(guò)程，闡釋著領(lǐng)域邏輯，指導(dǎo)著程序設(shè)計(jì)，驗(yàn)證著編碼質(zhì)量。
如果仔細(xì)審視這個(gè)設(shè)計(jì)閉環(huán)，我們發(fā)現(xiàn)在針對(duì)問(wèn)題域和業(yè)務(wù)期望提煉統(tǒng)一語(yǔ)言，并通過(guò)統(tǒng)一語(yǔ)言進(jìn)行領(lǐng)域建模時(shí)，可能會(huì)面臨高復(fù)雜度的挑戰(zhàn)。這是因?yàn)閷?duì)于一個(gè)復(fù)雜的軟件系統(tǒng)而言，我們要處理的問(wèn)題域?qū)嵲谔嫶罅恕Ｔ跒閱?wèn)題域?qū)で蠼鉀Q方案時(shí)，需要從宏觀層次劃分不同業(yè)務(wù)關(guān)注點(diǎn)的子領(lǐng)域，然后再深入到子領(lǐng)域中從微觀層次對(duì)領(lǐng)域進(jìn)行建模。宏觀層次是戰(zhàn)略的層面，微觀層次是戰(zhàn)術(shù)的層面，只有將戰(zhàn)略設(shè)計(jì)與戰(zhàn)術(shù)設(shè)計(jì)結(jié)合起來(lái)，才是完整的領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)。
戰(zhàn)略設(shè)計(jì) (Do Right Things)
Ubiquitous language
領(lǐng)域驅(qū)動(dòng)開(kāi)發(fā)讓業(yè)務(wù)專家(Domain Expert)和開(kāi)發(fā)人員一起來(lái)梳理業(yè)務(wù)，而雙方有效溝通的方式是使用通用語(yǔ)言，在這個(gè)項(xiàng)目里，一開(kāi)始我們就定義了很多詞匯表, 就是我們自己的通用語(yǔ)言。
Bounded Context 和 Domain
有了通用語(yǔ)言，詞匯表 每一個(gè)詞匯一定是有邊界的，不同的邊界內(nèi)是不一樣，比如你愛(ài)人在你家這個(gè) Bounded Context 是你的 Wife, 但是如果她是一個(gè)老師，那么在學(xué)校這個(gè)邊界里就是一個(gè) Teacher. 我們經(jīng)過(guò)多次討論，采取的方法是拆成多個(gè)子系統(tǒng)（Bounded Context,是不是很像現(xiàn)在的微服務(wù)？)，每個(gè)子系統(tǒng)進(jìn)行自治。
隨后我們把一個(gè)個(gè)業(yè)務(wù)抽象為領(lǐng)域?qū)ο?Domain Model), 每一個(gè) Domain 對(duì)領(lǐng)域進(jìn)行自治。而模型里的屬性和行為表達(dá)為業(yè)務(wù)專家都可以理解的代碼，用比如Job.Publish(). 雖然這里面最終產(chǎn)生了聚合根、實(shí)體、值對(duì)象等，但是我們和業(yè)務(wù)專家溝通的時(shí)候盡量不要說(shuō)這些詞匯，比如我們可以說(shuō)， 在招聘這塊兒，職位是不是必須經(jīng)過(guò)公司進(jìn)行管理，那樣我們就知道 Job 是屬于公司這個(gè)聚合根。 對(duì)領(lǐng)域進(jìn)行“通用”（類名，方法名等都用自然語(yǔ)言表達(dá)）建模，業(yè)務(wù)人員可以直接讀懂我們的代碼，從而可以知道是否表達(dá)了業(yè)務(wù)需求。
戰(zhàn)術(shù)設(shè)計(jì) (Do Things Right)
在戰(zhàn)術(shù)設(shè)計(jì)方面，由于業(yè)務(wù)行為和規(guī)則都在領(lǐng)域里，而且系統(tǒng)被拆分成多個(gè)子系統(tǒng)，這對(duì)技術(shù)實(shí)現(xiàn)上帶來(lái)了非常大的挑戰(zhàn)，尤其是大部分人都是有牢固的基于數(shù)據(jù)驅(qū)動(dòng)開(kāi)發(fā)的思想。 技術(shù)上有不同實(shí)現(xiàn)方式。
Event Sourcing
Event Sourcing 就是我們不記錄數(shù)據(jù)的最終狀態(tài)，我們記錄對(duì)數(shù)據(jù)的每一次改變(Event)，而讀取的時(shí)候我們把這些改變從頭再來(lái)一遍來(lái)取得數(shù)據(jù)狀態(tài)，比如你有100塊錢，現(xiàn)在剩下10塊了，我們記錄的不是money.total=10, 而是記錄你每一次取錢的記錄，然后從100塊開(kāi)始一步步重放你取錢的過(guò)程，來(lái)得到10.
一開(kāi)始，我們寫(xiě)的過(guò)程中，時(shí)常回想起數(shù)據(jù)驅(qū)動(dòng)的好，（每次開(kāi)始一個(gè)新東西的時(shí)候，是不是很熟悉的感覺(jué)？)，覺(jué)得用Event Sourcing各種麻煩，直到后來(lái)隨著系統(tǒng)的復(fù)雜性不斷增加，我們才感覺(jué)到帶來(lái)了非常大的好處, 這個(gè)隨后單獨(dú)來(lái)說(shuō)。
CQRS
由于使用了 Event Sourcing, 對(duì)數(shù)據(jù)查詢，尤其是跨業(yè)務(wù)(Aggregate)的查詢非常麻煩，很難像關(guān)系數(shù)據(jù)那樣有查詢優(yōu)勢(shì)，CQRS是解決這一問(wèn)題非常好的方法，CQRS讓查詢和寫(xiě)入分開(kāi)，把界面需要查詢的數(shù)據(jù)進(jìn)行原樣寫(xiě)入，原樣的意思就是界面顯示什么樣的，就提前保存成什么樣的，類似于原來(lái)的緩存，沒(méi)有任何join操作，這樣查詢是非常高效的。
- 圖片來(lái)源：http://vitiy.info/how-to-make-simple-cqrs-implementation-without-event-sourcing/
演進(jìn)的領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)過(guò)程
戰(zhàn)略設(shè)計(jì)會(huì)控制和分解戰(zhàn)術(shù)設(shè)計(jì)的邊界與粒度，戰(zhàn)術(shù)設(shè)計(jì)則以實(shí)證角度驗(yàn)證領(lǐng)域模型的有效性、完整性與一致性，進(jìn)而以演進(jìn)的方式對(duì)之前的戰(zhàn)略設(shè)計(jì)階段進(jìn)行迭代，從而形成一種螺旋式上升的迭代設(shè)計(jì)過(guò)程，如下圖所示：
面對(duì)客戶的業(yè)務(wù)需求，由領(lǐng)域?qū)＜遗c開(kāi)發(fā)團(tuán)隊(duì)展開(kāi)充分的交流，經(jīng)過(guò)需求分析與知識(shí)提煉，獲得清晰的問(wèn)題域。通過(guò)對(duì)問(wèn)題域進(jìn)行分析和建模，識(shí)別限界上下文，利用它劃分相對(duì)獨(dú)立的領(lǐng)域，再通過(guò)上下文映射建立它們之間的關(guān)系，輔以分層架構(gòu)與六邊形架構(gòu)劃分系統(tǒng)的邏輯邊界與物理邊界，界定領(lǐng)域與技術(shù)之間的界限。之后，進(jìn)入戰(zhàn)術(shù)設(shè)計(jì)階段，深入到限界上下文內(nèi)對(duì)領(lǐng)域進(jìn)行建模，并以領(lǐng)域模型指導(dǎo)程序設(shè)計(jì)與編碼實(shí)現(xiàn)。若在實(shí)現(xiàn)過(guò)程中，發(fā)現(xiàn)領(lǐng)域模型存在重復(fù)、錯(cuò)位或缺失時(shí)，再進(jìn)而對(duì)已有模型進(jìn)行重構(gòu)，甚至重新劃分限界上下文。
兩個(gè)不同階段的設(shè)計(jì)目標(biāo)是保持一致的，它們是一個(gè)連貫的過(guò)程，彼此之間又相互指導(dǎo)與規(guī)范，并最終保證一個(gè)有效的領(lǐng)域模型和一個(gè)富有表達(dá)力的實(shí)現(xiàn)同時(shí)演進(jìn)。
總結(jié)
結(jié)合自己的學(xué)習(xí)經(jīng)過(guò)，本篇有意識(shí)的避免了繁雜紛亂的「新概念」。如果有興趣詳細(xì)了解「DDD」中的那些概念，可以參照這篇文章：http://qinghua.github.io/ddd/
借大佬的總結(jié)來(lái)收個(gè)尾吧：領(lǐng)域驅(qū)動(dòng)開(kāi)發(fā)好處多多，概念比較多，門檻相對(duì)較高，對(duì)人員要求較高，團(tuán)隊(duì)里至少需要有領(lǐng)路人，不然代價(jià)會(huì)比較大。 尤其慎用Event Sourcing, 而領(lǐng)域驅(qū)動(dòng)尤其適合業(yè)務(wù)相對(duì)復(fù)雜的項(xiàng)目。 對(duì)那些很小的項(xiàng)目，CRUD仍然是好的選擇。
參考文章
- 淺談 MVC、MVP 和 MVVM 架構(gòu)模式：https://draveness.me/mvx
- 上善若水的博客：http://deshui.wang/
- CRUD工程師晉級(jí)之路：https://zhuanlan.zhihu.com/p/25442175
- 對(duì)象和數(shù)據(jù)庫(kù)的天然阻抗：https://www.jdon.com/mda/oo-reltaion2.html
- Commands & Events instead of CRUD?—?Part 1: Commands：https://hackernoon.com/commands-events-instead-of-crud-part-1-commands-17f4c7aee33b
- 湯雪華的博客：https://www.cnblogs.com/netfocus/
- There is No U in CRUD：http://jlhood.com/there-is-no-u-in-crud/
- Event sourcing vs CRUD：https://community.risingstack.com/event-sourcing-vs-crud/
- 阿里盒馬領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)實(shí)踐：https://www.infoq.cn/article/alibaba-freshhema-ddd-practice
- DDD戰(zhàn)略篇：架構(gòu)設(shè)計(jì)的響應(yīng)力：https://zhuanlan.zhihu.com/p/30878497
- 使用DDD來(lái)構(gòu)建你的REST API，而不是CRUD：http://blog.didispace.com/use-ddd-design-rest-api/
- DDD & co., part 1: What's wrong with CRUD：https://www.thenativeweb.io/blog/2017-10-25-09-46-ddd-and-co-part-1-whats-wrong-with-crud/
- DDD的終極大招——By Experience：https://insights.thoughtworks.cn/ddd-by-experience/
- 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)概覽：http://zhangyi.xyz/overview-of-ddd/
- Refactoring from anemic model to DDD：https://blog.pragmatists.com/refactoring-from-anemic-model-to-ddd-880d3dd3d45f
- 為什么DDD是設(shè)計(jì)微服務(wù)的最佳實(shí)踐：https://www.jianshu.com/p/e1b32a5ee91c
- 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)在互聯(lián)網(wǎng)業(yè)務(wù)開(kāi)發(fā)中的實(shí)踐：https://kb.cnblogs.com/page/586236/
按照慣例黏一個(gè)尾巴：
歡迎轉(zhuǎn)載，轉(zhuǎn)載請(qǐng)注明出處！
簡(jiǎn)書(shū)ID：@我沒(méi)有三顆心臟
github：wmyskxz
總結(jié)
以上是生活随笔為你收集整理的【吐血推荐】领域驱动设计学习输出的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 「消息队列」看过来！
- 下一篇： 你想了解的「SpringCloud」都在