【為什么要寫這本書】

2004 年，DDD（領(lǐng)域驅(qū)動設(shè)計）這一軟件開發(fā)的方法與愿景經(jīng)由建模專家 Eric Evans 的經(jīng)典著作Domain-Driven Design: Tackling Complexity in the Heart of Software 正式面世，當(dāng)即獲得了廣泛關(guān)注和高度評價。16 年過去了，我在網(wǎng)上看到越來越多關(guān)于 DDD的文章和討論。為什么我們現(xiàn)在還不停地討論 DDD？為什么DDD仍然如此重要？

在商業(yè)組織中，主張“技術(shù)為業(yè)務(wù)服務(wù)”的企業(yè)總可以在理論上立于不敗之地。誠然，DDD主張在軟件項目中把領(lǐng)域本身作為關(guān)注的焦點（換句話說就是技術(shù)人員要懂業(yè)務(wù)）符合這種思想，但真正難能可貴的是，DDD提供了切實可行的應(yīng)對軟件核心復(fù)雜性的方法。

實踐證明，DDD 提出的方法不僅行之有效，而且歷久彌新。關(guān)于這一點，我想從當(dāng)今 IT 業(yè)界的熱詞“云原生”“中臺”“產(chǎn)業(yè)互聯(lián)網(wǎng)”說起。

什么是云原生？云原生計算基金會（Cloud Native Computing Foundation，CNCF）對云原生的定義是：

云原生技術(shù)有利于各組織在公有云、私有云和混合云等新型動態(tài)環(huán)境中構(gòu)建和運行可彈性擴展的應(yīng)用。云原生的代表技術(shù)包括容器、服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明式 API。

這些技術(shù)能夠構(gòu)建容錯性好、易于管理和便于觀察的松耦合系統(tǒng)。結(jié)合可靠的自動化手段，云原生技術(shù)使工程師能夠輕松地對系統(tǒng)做出頻繁和可預(yù)測的重大變更。

而阿里云發(fā)布的《云原生架構(gòu)白皮書》 對云原生架構(gòu)的定義是：

從技術(shù)的角度看，云原生架構(gòu)是基于云原生技術(shù)的一組架構(gòu)原則和設(shè)計模式的集合，旨在將云應(yīng)用中的非業(yè)務(wù)代碼部分進(jìn)行最大化剝離，從而讓云設(shè)施接管應(yīng)用中原有的大量非功能特性（如彈性、韌性、安全、 可觀測性、灰度等），使業(yè)務(wù)不再有非功能性業(yè)務(wù)中斷困擾的同時，具備輕量、敏捷、高度自動化的特點。

看了這些定義，你是否還是覺得迷惑？打開CNCF的“l(fā)andscape”頁面——里面有很多的項目和成員，難怪有人說云原生是一個“營銷詞語”。在這個頁面中，在 Members（成員）這個標(biāo)簽頁的左邊，Serverless 獨占了一個標(biāo)簽頁，十分顯眼。

廣泛認(rèn)同的Serverless 架構(gòu)是指這樣的應(yīng)用設(shè)計：與第三方的后端即服務(wù)（Backend as a Service，BaaS）交互；在函數(shù)即服務(wù)（Function as a Service，F(xiàn)aaS）平臺上運行函數(shù)式業(yè)務(wù)代碼，一般來說，它們是在受管理的、臨時性的容器中執(zhí)行的。

雖然新出現(xiàn)的基于容器的 Serverless 平臺，比如 Knative，可以運行開發(fā)人員使用傳統(tǒng)方式開發(fā)的應(yīng)用，但 FaaS 仍然是 Serverless 中最重要、最具代表性的產(chǎn)品形態(tài)，因為它讓我們以一種不同于傳統(tǒng)的方式思考技術(shù)架構(gòu)。

FaaS 中的“Function”就是不依賴特定框架和類庫的最純粹的業(yè)務(wù)代碼——這是真正為業(yè)務(wù)帶來價值的東西�？梢哉f，F(xiàn)aaS在將云應(yīng)用中的非業(yè)務(wù)代碼部分進(jìn)行最大化剝離方面做到了極致。我認(rèn)為它是云原生“皇冠上的明珠”。

不過，大家普遍認(rèn)為當(dāng)前FaaS更適合開發(fā)事件驅(qū)動風(fēng)格的、處理少數(shù)幾個事件類型的應(yīng)用組件，而不適合開發(fā)傳統(tǒng)的具有很多入口的同步請求/響應(yīng)風(fēng)格的應(yīng)用組件。也就是說，如果你想問：“能不能基于 FaaS 做出一個 SAP ERP？”目前可能大多數(shù)人給你的答案會是“NO”。

但是我想給你的答案是“YES”！因為要想達(dá)到這個目標(biāo)，我們需要克服的所有障礙都不屬于 FaaS 的固有缺點，而是當(dāng)前FaaS 的實現(xiàn)缺陷，比如啟動延遲、集成測試、調(diào)試、交付、監(jiān)控與觀測等方面的問題。

我認(rèn)為，以 DDD 方法實現(xiàn)的應(yīng)用可以極大地降低 FaaS 處理這些問題的難度，甚至可以直接忽視某些問題（因為它們對以 DDD 方法實現(xiàn)的應(yīng)用來說不是問題）。具體而言，我們可以使用 DDD 的聚合概念來切分應(yīng)用組件，每個聚合一個小組件，它們可以很快地被 FaaS 平臺“拉起”。這些高度內(nèi)聚的小組件是更復(fù)雜的應(yīng)用組件（比如說領(lǐng)域服務(wù)）的構(gòu)造塊。我們可以使用興起于 DDD 社區(qū)的 Event Sourcing（事件溯源，ES）模式，保證應(yīng)用狀態(tài)的每一次變更都會發(fā)布領(lǐng)域事件，并以富含業(yè)務(wù)語義的事件驅(qū)動其他應(yīng)用組件運行。比如，命令查詢職責(zé)分離（Command Query Responsibility Segregation，CQRS）模式中的 Denormalizer（去規(guī)范化器）組件就可以訂閱、消費這些事件，為前端應(yīng)用構(gòu)建友好的查詢視圖——這些都是 DDD 社區(qū)在開發(fā)嚴(yán)肅的商業(yè)軟件時一直在做的事情。如果之前你沒有接觸過聚合、ES、CQRS，也許難以理解上面所說的內(nèi)容，不過沒關(guān)系，讀完本書，我相信你就清楚了。

再說“中臺”這個熱詞。以我的理解，中臺是將可復(fù)用的代碼抽取到一個平臺中，作為大家共用的軟件組件，它是服務(wù)于前臺的規(guī)�；瘎�(chuàng)新。中臺（這里主要指業(yè)務(wù)中臺）想要好用，必須具備“反映對領(lǐng)域的深度認(rèn)知”的軟件模型，甚至在某種程度上需要“過度設(shè)計”，并且絕對有必要維護(hù)良好的概念完整性，構(gòu)建所謂的企業(yè)級業(yè)務(wù)架構(gòu)——這些都是 DDD 可以大展身手的地方。

關(guān)于“產(chǎn)業(yè)互聯(lián)網(wǎng)即將進(jìn)入黃金時代”的說法，大多是眾多傳統(tǒng)企業(yè)希望借力最新的信息化，特別是互聯(lián)網(wǎng)工具（即所謂“互聯(lián)網(wǎng)+”），提升內(nèi)部效率和對外服務(wù)的能力。傳統(tǒng)產(chǎn)業(yè)中的很多領(lǐng)域概念和業(yè)務(wù)流程并不一定為普通的開發(fā)者所熟知——這與“消費互聯(lián)網(wǎng)”不同，顯然人人都是消費者。所以，傳統(tǒng)產(chǎn)業(yè)的信息化急需可以快速梳理并深刻地認(rèn)知領(lǐng)域，以及能構(gòu)建高質(zhì)量領(lǐng)域模型的技術(shù)人才。DDD 可以說是技術(shù)人員升職加薪的“神兵利器”。

我在工作中看到的情況是，越來越多的技術(shù)人員在自己的求職簡歷上寫上了“熟悉（或精通）DDD”的描述。確實，Eric Evans 的經(jīng)典著作以抽象、凝練著稱，可謂字字珠璣，甚至很多資深技術(shù)人員都不能領(lǐng)悟其中玄妙。所以，我也認(rèn)同掌握 DDD 是一件足以讓技術(shù)人員引以為傲的事情。

可以說，DDD 是公認(rèn)的解決軟件核心復(fù)雜性的“大殺器”。但是，在軟件開發(fā)中實踐 DDD 是需要付出相當(dāng)大的成本的。也就是說，大家的普遍看法是：實踐 DDD 是一個先苦后甜的過程，一個項目要不要采用DDD，最好先看看它值不值得。

但是一個項目值不值得使用 DDD 有時不好判斷。大項目往往是由小項目發(fā)展而來的，很多從小項目演化而來的大系統(tǒng)最終變成開發(fā)團隊的噩夢，噩夢的根源幾乎無一例外地在于軟件的概念完整性遭到了破壞。而DDD正是維護(hù)軟件概念完整性的良藥。如果在項目中實踐 DDD 的成本不高，那么即使是小項目，從一開始就使用 DDD 不是一件很美好的事情嗎？

在軟件開發(fā)項目中實踐 DDD 到底有何難處？16 年了，難道在 DDD 實踐中碰到的問題我們不能從書本中尋得答案？

目前國內(nèi)已經(jīng)出版的DDD相關(guān)圖書中，除了 Eric Evans 的經(jīng)典著作之外，還有《實現(xiàn)領(lǐng)域驅(qū)動設(shè)計》《領(lǐng)域驅(qū)動設(shè)計精粹》《領(lǐng)域驅(qū)動設(shè)計模式、原理與實踐》等，不過寥寥數(shù)本。這與 DDD 的巨大聲望很不匹配，這也許說明了一些問題。

實踐DDD首先需要面對的一個（也許是最大的）難題是：難以描述的領(lǐng)域模型。

DDD 想要構(gòu)建的領(lǐng)域模型是什么？按照 Eric Evans 的觀點，領(lǐng)域模型不是一幅具體的圖，而是那幅圖想要傳達(dá)的思想；不是一個領(lǐng)域?qū)＜翌^腦中的知識，而是那些經(jīng)過嚴(yán)格組織并進(jìn)行選擇性抽象的知識。

聽起來是不是有點玄奧？系統(tǒng)分析師、產(chǎn)品經(jīng)理到底要拿出什么樣的領(lǐng)域模型才能說

“我的工作已經(jīng)做到位了”？這個模型到底是不是可以實現(xiàn)的？開發(fā)人員、測試人員到底有沒有理解這個模型？大家的理解是不是一致的？

說到底，一個領(lǐng)域模型要想有用，它必須足夠嚴(yán)格。如何使用一種嚴(yán)格的方式描述經(jīng)過嚴(yán)格組織并進(jìn)行選擇性抽象的知識呢？

問題的答案很自然地指向了 DSL。

其實，Eric Evans 早就意識到了這一點。他曾經(jīng)在訪談中說：

更多前沿的話題發(fā)生在領(lǐng)域?qū)Ｓ谜Z言（DSL）領(lǐng)域，我一直深信 DSL 會是領(lǐng)域驅(qū)動設(shè)計發(fā)展的下一大步�，F(xiàn)在，還沒有一個工具可以真正給我們想要的東西。但是人們在這一領(lǐng)域比過去做了更多的實驗，這使我對未來充滿了希望。

通過本書，我想要告訴大家的是：在項目中運用 DDD 可以不像大家想象的那么痛苦，DDD 并不是只適用于大項目，使用 DDD 并不一定需要犧牲敏捷性，一切的關(guān)鍵在于 DSL 的運用。

我和我工作過的團隊曾經(jīng)在多個項目中使用 DSL 實現(xiàn)了 DDD 的真正落地。獨樂樂不如眾樂樂！現(xiàn)在，我想把這些實踐經(jīng)驗分享給大家。

【讀者對象】

領(lǐng)域模型是一種“思想”，它可以為軟件開發(fā)的全過程提供指導(dǎo)，所以我相信本書可以為很多人提供幫助：

產(chǎn)品經(jīng)理與系統(tǒng)分析師。產(chǎn)品經(jīng)理不僅僅需要保證團隊開發(fā)的是“正確的軟件”，也不應(yīng)該只是關(guān)注軟件的界面原型、用戶體驗，更應(yīng)該讓軟件有內(nèi)涵。迷人的產(chǎn)品不僅需要漂亮的界面和交互，更需要邏輯自洽，功能處處傳達(dá)出一個思想——優(yōu)美而深刻的領(lǐng)域模型。在有的團隊中，產(chǎn)品經(jīng)理同時也是系統(tǒng)分析師。作為近十幾年來最有影響力的軟件分析和設(shè)計的方法論，系統(tǒng)分析師有必要了解DDD，從中汲取營養(yǎng)。

架構(gòu)師。架構(gòu)師需要根據(jù)業(yè)務(wù)需求提供技術(shù)解決方案。DDD 想要構(gòu)建的領(lǐng)域模型不僅僅是領(lǐng)域業(yè)務(wù)知識的提煉總結(jié)，也包含了對軟件設(shè)計的考量，可以用于直接指導(dǎo)軟件的編碼實現(xiàn)。構(gòu)建這樣的模型，需要架構(gòu)師的積極參與。

開發(fā)工程師。開發(fā)工程師應(yīng)該理解領(lǐng)域模型，領(lǐng)域模型應(yīng)該被忠實地映射到代碼實現(xiàn)中。代碼中對象的命名、對象之間的關(guān)系，都應(yīng)該與領(lǐng)域模型一致。唯有如此，代碼才能具備良好的可讀性、可維護(hù)性，敏捷 XP 方法的狂熱愛好者們所言的“代碼即文檔”才可能實現(xiàn)。

測試工程師。如今很多測試工程師已經(jīng)被稱為“測試開發(fā)工程師”，他們也應(yīng)該理解領(lǐng)域模型。測試工程師應(yīng)該像產(chǎn)品經(jīng)理一樣了解軟件的設(shè)計，甚至應(yīng)該比產(chǎn)品經(jīng)理更深刻地理解領(lǐng)域模型面向軟件設(shè)計所做的考量。實例化需求的自動化測試（或者說行為驅(qū)動測試）應(yīng)該基于領(lǐng)域模型，而非基于 UI/UE 來構(gòu)建，因為用戶界面以及用戶交互是易變的，而領(lǐng)域模型相對來說穩(wěn)定得多。

項目經(jīng)理。項目經(jīng)理是負(fù)責(zé)“正確開發(fā)軟件”的人。如果不深刻理解領(lǐng)域，不知道如何抓住領(lǐng)域模型中的關(guān)鍵點，會很難評估任務(wù)工作量的大小以及應(yīng)該在何處投入足夠的資源，甚至無法判斷項目的實際進(jìn)度。

高校研究生以及其他有志于從事 IT 行業(yè)的人。

【如何閱讀本書】

本書的第一部分會帶領(lǐng)讀者從戰(zhàn)術(shù)層面以及戰(zhàn)略層面重溫領(lǐng)域驅(qū)動設(shè)計的重要概念，然后進(jìn)一步闡述Eric Evans經(jīng)典著作中沒有顯式提出的或者被太多人忽略的但我認(rèn)為對 DDD 落地非常重要的若干概念，同時簡要介紹從 DDD 社區(qū)興起的一些軟件架構(gòu)模式。通過第一部分，讀者可以更完整、更深刻地掌握 DDD 的知識體系。

第二部分闡述如何設(shè)計一種DDD的DSL，包括這個DSL的規(guī)范（Specification）支持哪些特性、如何幫助團隊描述領(lǐng)域模型的方方面面、這些特性的選擇基于何種考量等。

這種領(lǐng)域?qū)Ｓ谜Z言需要一個名字，我們總不能一直說“我設(shè)計的 DDD 的 DSL”吧，于是我給它起了一個名字：DDDML。我認(rèn)為這是一個很棒的名字。其實這種語言叫什么并不太重要，重要的是它可以用一種足夠嚴(yán)格的方式描述領(lǐng)域模型。我認(rèn)為目前它在簡單與復(fù)雜之間取得了不錯的平衡。當(dāng)然，其中還有不小改進(jìn)的空間。比如，我很樂意讓它支持更多像“賬務(wù)模式”這樣的分析模式。

第三部分介紹如何將“思想照進(jìn)實現(xiàn)”——通過使用工具將描述領(lǐng)域模型的 DSL 文檔變成可以運行的軟件。這個過程涉及大量的技術(shù)工具（工具鏈）的設(shè)計與實現(xiàn)。只有將這些技術(shù)工具——比如從 DSL 自動生成應(yīng)用的源代碼的模板——實現(xiàn)出來，才能減輕開發(fā)人員實踐 DDD 的負(fù)擔(dān)，進(jìn)而提升而不是降低軟件團隊的生產(chǎn)效率。本部分會介紹這些技術(shù)工具設(shè)計與實現(xiàn)的細(xì)節(jié)。

我和我的同事把自制的 DDDML 工具鏈稱為 DDDML Tools。出于商業(yè)原因，我無法展示這些工具的源代碼，但是會詳盡地展示這些工具運行的結(jié)果——主要是由工具生成的應(yīng)用的源代碼。這些源代碼可能經(jīng)過一些簡化，但是與我們在生產(chǎn)系統(tǒng)上運行的代碼十分接近，完全可以說明問題。

讀完全書，你將發(fā)現(xiàn)其實我們已經(jīng)全無秘密。你會熟知 DDDML 的規(guī)范，見到工具運行的結(jié)果，你幾乎可以馬上動手制造自己的 DDDML 工具。其實設(shè)計 DDDML 的規(guī)范才是整件事情（使用 DSL 實現(xiàn)領(lǐng)域驅(qū)動設(shè)計）中最難的部分，制作工具不是。雖然想要復(fù)刻我們已經(jīng)做過的所有工具確實需要相當(dāng)大的工作量，但也僅僅是工作量而已。

幸運的是，你并不需要制造整條 DDDML 的工具鏈才可以享受使用 DSL 的樂趣。比如，你可以先寫一些模板，生成一些持久對象（Persistant Object），它們無非是一些簡單的 Java 對象（Plain Ordinary Java Object，POJO），然后再生成一些 O/R Mapping XML，就可以馬上使用 JPA/Hibernate 來實現(xiàn)應(yīng)用的 DAL（數(shù)據(jù)訪問層）了。如果你再生成 Repository，那就更漂亮啦！

第四部分講述的是一些建模案例以及其他與 DDD 相關(guān)的話題。領(lǐng)域模型是一種思想，DSL 是一種工具，但是如何運用、結(jié)果如何，因人而異。我希望通過輕松的漫談和隨想，將我的一點DDD應(yīng)用經(jīng)驗分享給大家。