從遇到問題開始

當人們要做一個軟件系統(tǒng)時，一般總是因為遇到了什么問題，然后希望通過一個軟件系統(tǒng)來解決。

比如，我是一家企業(yè)，然后我覺得我現(xiàn)在線下銷售自己的產(chǎn)品還不夠，我希望能夠在線上也能銷售自己的產(chǎn)品。所以，自然而然就想到要做一個普通電商系統(tǒng)，用于實現(xiàn)在線銷售自己企業(yè)產(chǎn)品的目的。

再比如，我是一家互聯(lián)網(wǎng)公司，公司有很多系統(tǒng)對外提供服務，面向很多客戶端設備。但是最近由于各種原因，導致服務經(jīng)常出故障。所以，我們希望通過各種措施提高服務的質(zhì)量和穩(wěn)定性。其中的一個措施就是希望能做一個灰度發(fā)布的平臺，這個平臺可以提供灰度發(fā)布的服務。然后，當某個業(yè)務系統(tǒng)做了一些修改并需要發(fā)布時，可以使用我們的灰度發(fā)布平臺來非常方便的實現(xiàn)灰度發(fā)布的功能。比如在灰度發(fā)布平臺上方便的定制允許哪些特定的客戶端才會訪問新服務，哪些客戶端繼續(xù)使用老服務。灰度發(fā)布平臺可以提供各種灰度的策略。有了這樣的灰度發(fā)布機制，那即便系統(tǒng)的新邏輯有什么問題，受影響的面也不會很大，在可控范圍內(nèi)。所以，如果公司里的所有對外提供服務的系統(tǒng)都接入了灰度平臺，那這些系統(tǒng)的發(fā)布環(huán)節(jié)就可以更加有保障了。

總之，我們做任何一個軟件系統(tǒng)，都是有原因的，否則就沒必要做這個系統(tǒng)，而這個原因就是我們遇到的問題。所以，通過問題，我們就知道了我們需要一個什么樣的系統(tǒng)，這個系統(tǒng)解決什么樣的問題。***，我們就很自然的得出了一個目標，即知道了自己要什么。比如我要做一個論壇、一個博客系統(tǒng)、一個電商平臺、一個灰度發(fā)布系統(tǒng)、一個IDE、一個分布式消息隊列、一個通信框架，等等。

DDD切入點1 - 理解概念

DDD的全稱為Domain-driven Design，即領(lǐng)域驅(qū)動設計。下面我從領(lǐng)域、問題域、領(lǐng)域模型、設計、驅(qū)動這幾個詞語的含義和聯(lián)系的角度去闡述DDD是如何融入到我們平時的軟件開發(fā)初期階段的。要理解什么是領(lǐng)域驅(qū)動設計，首先要理解什么是領(lǐng)域，什么是設計，還有驅(qū)動是什么意思，什么驅(qū)動什么。

什么是領(lǐng)域（Domain）？

前面我們已經(jīng)清楚的知道我們現(xiàn)在要做一個什么樣的系統(tǒng)，這個系統(tǒng)需要解決什么問題。我認為任何一個系統(tǒng)都會屬于某個特定的領(lǐng)域，比如論壇是一個領(lǐng)域，只要你想做一個論壇，那這個論壇的核心業(yè)務是確定的，比如都有用戶發(fā)帖、回帖等核心基本功能。比如電商平臺、普通電商系統(tǒng)，這種都屬于網(wǎng)上電商領(lǐng)域，只要是這個領(lǐng)域的系統(tǒng)，那都有商品瀏覽、購物車、下單、減庫存、付款交易等核心環(huán)節(jié)。所以，同一個領(lǐng)域的系統(tǒng)都具有相同的核心業(yè)務，因為他們要解決的問題的本質(zhì)是類似的。

因此，我們可以推斷出，一個領(lǐng)域本質(zhì)上可以理解為就是一個問題域，只要是同一個領(lǐng)域，那問題域就相同。所以，只要我們確定了系統(tǒng)所屬的領(lǐng)域，那這個系統(tǒng)的核心業(yè)務，即要解決的關(guān)鍵問題、問題的范圍邊界就基本確定了。通常我們說，要成為一個領(lǐng)域的專家，必須要在這個領(lǐng)域深入研究很多年才行。因為只有你研究了很多年，你才會遇到非常多的該領(lǐng)域的問題，同時你解決這個領(lǐng)域中的問題的經(jīng)驗也非常豐富。很多時候，領(lǐng)域?qū)＜冶燃夹g(shù)專家更加吃香，比如金融領(lǐng)域的專家。

什么是設計（Design）？

DDD中的設計主要指領(lǐng)域模型的設計。為什么是領(lǐng)域模型的設計而不是架構(gòu)設計或其他的什么設計呢？因為DDD是一種基于模型驅(qū)動開發(fā)的軟件開發(fā)思想，強調(diào)領(lǐng)域模型是整個系統(tǒng)的核心，領(lǐng)域模型也是整個系統(tǒng)的核心價值所在。每一個領(lǐng)域，都有一個對應的領(lǐng)域模型，領(lǐng)域模型能夠很好的幫我們解決復雜的業(yè)務問題。

從領(lǐng)域和代碼實現(xiàn)的角度來理解，領(lǐng)域模型綁定了領(lǐng)域和代碼實現(xiàn)，確保了最終的代碼實現(xiàn)就一定是解決了領(lǐng)域中的核心問題的。因為：1）領(lǐng)域驅(qū)動領(lǐng)域模型設計；2）領(lǐng)域模型驅(qū)動代碼實現(xiàn)。我們只要保證領(lǐng)域模型的設計是正確的，就能確定領(lǐng)域模型可以解決領(lǐng)域中的核心問題；同理，我們只要保證代碼實現(xiàn)是嚴格按照領(lǐng)域模型的意圖來落地的，那就能保證***出來的代碼能夠解決領(lǐng)域的核心問題的。這個思路，和傳統(tǒng)的分析、設計、編碼這幾個階段被割裂（并且每個階段的產(chǎn)物也不同）的軟件開發(fā)方法學形成鮮明的對比。

什么是驅(qū)動（Driven）？

上面其實已經(jīng)提到了，就是：1）領(lǐng)域驅(qū)動領(lǐng)域模型設計；2）領(lǐng)域模型驅(qū)動代碼實現(xiàn)。這個就和我們傳統(tǒng)的數(shù)據(jù)庫驅(qū)動開發(fā)的思路形成對比了。DDD中，我們總是以領(lǐng)域為邊界，分析領(lǐng)域中的核心問題（核心關(guān)注點），然后設計對應的領(lǐng)域模型，再通過領(lǐng)域模型驅(qū)動代碼實現(xiàn)。而像數(shù)據(jù)庫設計、持久化技術(shù)等這些都不是DDD的核心，而是外圍的東西。

領(lǐng)域驅(qū)動設計（DDD）告訴我們的***價值我覺得是：當我們要開發(fā)一個系統(tǒng)時，應該盡量先把領(lǐng)域模型想清楚，然后再開始動手編碼，這樣的系統(tǒng)后期才會很好維護。但是，很多項目（尤其是互聯(lián)網(wǎng)項目，為了趕工）都是一開始模型沒想清楚，一上來就開始建表寫代碼，代碼寫的非常冗余，完全是過程是的思考方式，***導致系統(tǒng)非常難以維護。而且更糟糕的是，出來混總是要還的，前期的領(lǐng)域模型設計的不好，不夠抽象，如果你的系統(tǒng)會長期需要維護和適應業(yè)務變化，那后面你一定會遇到各種問題維護上的困難，比如數(shù)據(jù)結(jié)構(gòu)設計不合理，代碼到處冗余，改BUG到處引入新的BUG，新人對這種代碼上手困難，等。而那時如果你再想重構(gòu)模型，那要付出的代價會比一開始重新開發(fā)還要大，因為你還要考慮兼容歷史的數(shù)據(jù)，數(shù)據(jù)遷移，如何平滑發(fā)布等各種頭疼的問題。所以，就導致我們***天天加班。

雖然，我們都知道這個道理，但是我也明白，人的習慣很難改變的，大部分人都很難從面向過程式的想到哪里寫到哪里的思想轉(zhuǎn)變?yōu)榛谙到y(tǒng)化的模型驅(qū)動的思維。我想，這或許是DDD很難在中國或國外流行起來的原因吧。但是，我想這不應該成為我們放棄學習DDD的原因，對吧！

概念總結(jié)：

1. 領(lǐng)域就是問題域，有邊界，領(lǐng)域中有很多問題；
2. 任何一個系統(tǒng)要解決的那個大問題都對應一個領(lǐng)域；
3. 通過建立領(lǐng)域模型來解決領(lǐng)域中的核心問題，模型驅(qū)動的思想；
4. 領(lǐng)域建模的目標針對我們在領(lǐng)域中所關(guān)心的問題，即只針對核心關(guān)注點，而不是整個領(lǐng)域中的所有問題；
5. 領(lǐng)域模型在設計時應考慮一定的抽象性、通用性，以及復用價值；
6. 通過領(lǐng)域模型驅(qū)動代碼的實現(xiàn)，確保代碼讓領(lǐng)域模型落地，代碼最終能解決問題；
7. 領(lǐng)域模型是系統(tǒng)的核心，是領(lǐng)域內(nèi)的業(yè)務的直接沉淀，具有非常大的業(yè)務價值；
8. 技術(shù)架構(gòu)設計或數(shù)據(jù)存儲等是在領(lǐng)域模型的外圍，幫助領(lǐng)域模型進行落地；

DDD切入點2 - 理解領(lǐng)域、拆分領(lǐng)域、細化領(lǐng)域

理解領(lǐng)域知識是基礎

上面我們通過***步，雖然我們明確了要做一個什么樣的系統(tǒng)，該系統(tǒng)主要解決什么問題，但是就這樣我們還無法開始進行實際的需求分析和模型設計，我們還必須將我們的問題進行拆分，需求進行細化。有些時候，需求方，即提出問題的人，很可能自己不清楚具體想要什么。他只知道一個概念，一個大的目標。比如他只知道要做一個股票交易系統(tǒng)，一個灰度發(fā)布系統(tǒng)，一個電商平臺，一個開發(fā)工具，等。但是他不清楚這些系統(tǒng)應該具體做成什么樣子。這個時候，我認為領(lǐng)域?qū)＜揖头浅Ｖ匾耍珼DD也非常強調(diào)領(lǐng)域?qū)＜业闹匾浴Ｒ驗轭I(lǐng)域?qū)＜覍@個領(lǐng)域非常了解，對領(lǐng)域內(nèi)的各種業(yè)務場景和各種業(yè)務規(guī)則也非常清楚，總之，對這個領(lǐng)域內(nèi)的一切業(yè)務相關(guān)的知識都非常了解。所以，他們自然就有能力表達出系統(tǒng)該做成什么樣子。所以，要知道一個系統(tǒng)到底該做成什么樣子，到底哪些是核心業(yè)務關(guān)注點，只能靠沉淀領(lǐng)域內(nèi)的各種知識，別無他法。因此，假設你現(xiàn)在打算做一個電商平臺，但是你對這個領(lǐng)域沒什么了解，那你一定得先去了解下該領(lǐng)域內(nèi)主流的電商平臺，比如淘寶、天貓、京東、亞馬遜等。這個了解的過程就是你沉淀領(lǐng)域知識的過程。如果你不了解，就算你領(lǐng)域建模的能力再強，各種技術(shù)架構(gòu)能力再強也是使不上力。領(lǐng)域?qū)＜也皇悄硞€固定的角色，而是某一類人，這類人對這個領(lǐng)域非常了解。比如，一個開發(fā)人員也可以是一個領(lǐng)域?qū)＜摇＜僭O你在一個公司開發(fā)和維護一個系統(tǒng)已經(jīng)好幾年了，但是這個系統(tǒng)的產(chǎn)品經(jīng)理（PD）可能已經(jīng)換過好幾任了，這種情況下，我相信這幾任產(chǎn)品經(jīng)理都沒有比你更熟悉這個領(lǐng)域。

拆分領(lǐng)域

上面我們明白了，領(lǐng)域建模的基礎是要先理解領(lǐng)域，讓自己成為領(lǐng)域?qū)＜摇Ｈ绻龅搅诉@點，我們就打好了堅實的基礎了。但是，有時一個領(lǐng)域往往太復雜，涉及到的領(lǐng)域概念、業(yè)務規(guī)則、交互流程太多，導致我們沒辦法直接針對這個大的領(lǐng)域進行領(lǐng)域建模。所以，我們需要將領(lǐng)域進行拆分，本質(zhì)上就是把大問題拆分為小問題，然后各個擊破的思路。然后既然把一個大的領(lǐng)域劃分為了多個小的領(lǐng)域（子域），那最關(guān)鍵的就是要理清每個子域的邊界；然后要搞清楚哪些子域是核心子域，哪些是非核心子域，哪些是公共支撐子域；然后，還要思考子域之間的聯(lián)系是什么。那么，我們該如何劃分子域呢？我的個人看法是從業(yè)務相關(guān)性的角度去思考，也就是我們平時說的按業(yè)務功能為出發(fā)點進行劃分。還是拿經(jīng)典的電商系統(tǒng)來分析，通常一個電商系統(tǒng)都會包含好幾個大塊，比如：

• 會員中心：負責用戶賬號登錄、用戶信息的管理；
• 商品中心：負責商品的展示、導航、維護；
• 訂單中心：負責訂單的生成和生命周期管理；
• 交易中心：負責交易相關(guān)的業(yè)務；
• 庫存中心：負責維護商品的庫存；
• 促銷中心：負責各種促銷活動的支持；

上面這些中心看起來很自然，因為大家對電子商務的這個領(lǐng)域都已經(jīng)非常熟悉了，所以都沒什么疑問，好像很自然的樣子。所以，領(lǐng)域劃分是不是就是沒什么挑戰(zhàn)了呢？顯然不是。之所以我們覺得子域劃分很簡單，是因為我們對整個大領(lǐng)域非常了解了。如果我們遇到一個冷門的領(lǐng)域，就沒辦法這么容易的去劃分子域了。這就需要我們先去努力理解領(lǐng)域內(nèi)的知識。所以，我個人從來不相信什么子域劃分的技巧什么的東西，因為我覺得這個工作沒有任何訣竅可以使用。當我們不了解一個東西的時候，如何去拆解它？當我們對整個領(lǐng)域有一定的熟悉了，了解了領(lǐng)域內(nèi)的相關(guān)業(yè)務的本質(zhì)和關(guān)系，我們就自然而然的能劃分出合理的子域了。不過并不是所有的系統(tǒng)都需要劃分子域的，有些系統(tǒng)只是解決一個小問題，這個問題不復雜，可能只有一兩個核心概念。所以，這種系統(tǒng)完全不需要再劃分子域。但不是絕對的，當一個領(lǐng)域，我們的關(guān)注點越來越多，每個關(guān)注點我們關(guān)注的信息越來越多的時候，我們會不由自主的去進一步的劃分子域。比如，也許我們一開始將商品和商品的庫存都放在商品中心里，但是后來由于庫存的維護越來越復雜，導致揉在一起對我們的系統(tǒng)維護帶來一定的困難時，我們就會考慮將兩者進行拆分，這個就是所謂的業(yè)務垂直分割。

細化子域

通過上面的兩步，我們了解了領(lǐng)域里的知識，也對領(lǐng)域進行了子域劃分。但這樣還不夠，憑這些我們還無法進行后續(xù)的領(lǐng)域模型設計。我們還必須再進一步細化每個子域，進一步明確每個子域的核心關(guān)注點，即需求細化。我覺得我們需要細化的方面有以下幾點：

1. 梳理領(lǐng)域概念：梳理出領(lǐng)域內(nèi)我們關(guān)注的概念、概念的關(guān)系，并統(tǒng)一交流詞匯，形成統(tǒng)一語言；
2. 梳理業(yè)務規(guī)則：梳理出領(lǐng)域內(nèi)我們關(guān)注的各種業(yè)務規(guī)則，DDD中叫不變性（invariants），比如唯一性規(guī)則，余額不能小于零等；
3. 梳理業(yè)務場景：梳理出領(lǐng)域內(nèi)的核心業(yè)務場景，比如電商平臺中的加入購物車、提交訂單、發(fā)起付款等核心業(yè)務場景；
4. 梳理業(yè)務流程：梳理出領(lǐng)域內(nèi)的關(guān)鍵業(yè)務流程，比如訂單處理流程，退款流程等；

從上面這4個方面，我們從領(lǐng)域概念、業(yè)務規(guī)則、交互場景、業(yè)務流程等維度梳理了我們到底要什么，整理了整個系統(tǒng)應該具備的功能。這個工作我覺得是一個非常具有創(chuàng)造性和有難度的工作。我們一方面會主觀的定義我們想要什么；另一方面，我們還會思考我們要的東西的合理性。我認為這個就是產(chǎn)品經(jīng)理的工作，產(chǎn)品經(jīng)理必須要負起職責，把他的產(chǎn)品充分設計好，從各個方面去考慮，如何設計一個產(chǎn)品，才能更好的解決用戶的核心訴求，即領(lǐng)域內(nèi)的核心問題。如果對領(lǐng)域不夠了解，如果想不清楚用戶到底要什么，如果思考問題不夠全面，談何設計出一個合理的產(chǎn)品呢？

關(guān)于領(lǐng)域概念的梳理，我覺得可以采用四色原型分析法，這個分析法通過系統(tǒng)的方法，將概念劃分為不同的種類，為不同種類的概念標注不同的顏色。然后將這些概念有機的組合起來，從而讓我們可以清晰的分析出概念和概念之間的關(guān)系。有興趣的同學可以在網(wǎng)上搜索下四色原型。

注意：上面我說的這四點，重點是梳理出我們要什么功能，而不是思考如何實現(xiàn)這些功能，如何實現(xiàn)是軟件設計人員的職責。

DDD切入點3 - 領(lǐng)域模型設計

這部分內(nèi)容，我想學習DDD的人都很熟悉了。DDD原著中提出了很多實用的建模工具：聚合、實體、值對象、工廠、倉儲、領(lǐng)域服務、領(lǐng)域事件。我們可以使用這些工具，來設計每一個子域的領(lǐng)域模型。最終通過領(lǐng)域模型圖將設計沉淀下來。要使用這些工具，首先就要理解每個工具的含義和使用場景。不要以為很簡單哦，比如聚合的劃分就是一個非常具有藝術(shù)的活。同一個系統(tǒng)，不同的人設計出來的聚合是完全不同的。而且很有可能高手之間的***設計出來的差別反而更大，實際上我認為是世界觀的相互碰撞，呵呵。所以，要領(lǐng)域建模，我覺得每個人都應該去學學哲學知識，這有助于我們更好的認識世界，更好的理解事物的本質(zhì)。

關(guān)于這些建模工具的概念和如何運用我就不多展開了，我博客里也有很多這方面的介紹。下面我再講一下我認為比較重要的東西，比如到底該如何領(lǐng)域建模？步驟應該是怎么樣的？

領(lǐng)域建模的方法

通過上面我介紹的細化子域的內(nèi)容，現(xiàn)在再來談該如何領(lǐng)域建模，我覺得就方便很多了。我的主要方法是：

1. 劃分好邊界上下文，通常每個子域（sub domain）對應一個邊界上下文（bounded context），同一個邊界上下文中的概念是明確的，沒有任何歧義；
2. 在每個邊界上下文中設計領(lǐng)域模型，具體的領(lǐng)域模型設計方法有很多種，如以場景為出發(fā)點的四色原型分析法，或者我早期寫的這篇文章；這個步驟最核心的就是找出聚合根，并找出每個聚合根包含的信息；關(guān)于如何設計聚合，可以看一下我寫的這篇文章；
3. 畫出領(lǐng)域模型圖，圈出每個模型中的聚合邊界；
4. 設計領(lǐng)域模型時，要考慮該領(lǐng)域模型是否滿足業(yè)務規(guī)則，同時還要綜合考慮技術(shù)實現(xiàn)等問題，比如并發(fā)問題；領(lǐng)域模型不是概念模型，概念模型不關(guān)注技術(shù)實現(xiàn)，領(lǐng)域模型關(guān)心；所以領(lǐng)域模型才能直接指導編碼實現(xiàn)；
5. 思考領(lǐng)域模型是如何在業(yè)務場景中發(fā)揮作用的，以及是如何參與到業(yè)務流程的每個環(huán)節(jié)的；
6. 場景走查，確認領(lǐng)域模型是否能滿足領(lǐng)域中的業(yè)務場景和業(yè)務流程；
7. 模型持續(xù)重構(gòu)、完善、精煉；

領(lǐng)域模型的核心作用：

1. 抽象了領(lǐng)域內(nèi)的核心概念，并建立概念之間的關(guān)系；
2. 領(lǐng)域模型承擔了領(lǐng)域內(nèi)的狀態(tài)的維護；
3. 領(lǐng)域模型維護了領(lǐng)域內(nèi)的數(shù)據(jù)之間的業(yè)務規(guī)則，數(shù)據(jù)一致性；

下圖是我最近做個一個普通電商系統(tǒng)的商品中心的領(lǐng)域模型圖，給大家參考：

領(lǐng)域模型設計只是軟件設計中的一小部分

需要特別注意的是，領(lǐng)域模型設計只是整個軟件設計中的很小一部分。除了領(lǐng)域模型設計之外，要落地一個系統(tǒng)，我們還有非常多的其他設計要做，比如：

• 容量規(guī)劃
• 架構(gòu)設計
• 數(shù)據(jù)庫設計
• 緩存設計
• 框架選型
• 發(fā)布方案
• 數(shù)據(jù)遷移、同步方案
• 分庫分表方案
• 回滾方案
• 高并發(fā)解決方案
• 一致性選型
• 性能壓測方案
• 監(jiān)控報警方案

等等。上面這些都需要我們平時的大量學習和積累。作為一個合格的開發(fā)人員或架構(gòu)師，我覺得除了要會DDD領(lǐng)域驅(qū)動設計，還要會上面這么多的技術(shù)能力，確實是非常不容易的。所以，千萬不要以為會DDD了就以為自己很牛逼，實際上你會的只是軟件設計中的冰山一角而已。

總結(jié)

本文的重點是基于我個人對DDD的一些理解，希望能整理出一些自己總結(jié)出來的一些感悟和經(jīng)驗，并分享給大家。我相信很多人已經(jīng)看過太多DDD書上的東西，我總是感覺書上的東西看似都太”正規(guī)“，很多時候我們讀了之后很難消化，就算理解了書里的內(nèi)容，當我們想要運用到實踐中時，總是感覺無從下手。本文希望通過通俗易懂的文字，介紹了一部分我對DDD的學習感悟和實踐心得，希望能給大家一些啟發(fā)和幫助。