從遇到問題開始

當人們要做一個軟體系統時，一般總是因為遇到了什麼問題，然後希望通過一個軟體系統來解決。

比如，我是一家企業，然後我覺得我現線上下銷售自己的產品還不夠，我希望能夠在線上也能銷售自己的產品。所以，自然而然就想到要做一個普通電商系統，用於實現線上銷售自己企業產品的目的。

再比如，我是一家網際網路公司，公司有很多系統對外提供服務，面向很多客戶端裝置。但是最近由於各種原因，導致服務經常出故障。所以，我們希望通過各種措施提高服務的質量和穩定性。其中的一個措施就是希望能做一個灰度釋出的平臺，這個平臺可以提供灰度釋出的服務。然後，當某個業務系統做了一些修改並需要釋出時，可以使用我們的灰度釋出平臺來非常方便的實現灰度釋出的功能。比如在灰度釋出平臺上方便的定製允許哪些特定的客戶端才會訪問新服務，哪些客戶端繼續使用老服務。灰度釋出平臺可以提供各種灰度的策略。有了這樣的灰度釋出機制，那即便系統的新邏輯有什麼問題，受影響的面也不會很大，在可控範圍內。所以，如果公司裡的所有對外提供服務的系統都接入了灰度平臺，那這些系統的釋出環節就可以更加有保障了。

總之，我們做任何一個軟體系統，都是有原因的，否則就沒必要做這個系統，而這個原因就是我們遇到的問題。所以，通過問題，我們就知道了我們需要一個什麼樣的系統，這個系統解決什麼樣的問題。最後，我們就很自然的得出了一個目標，即知道了自己要什麼。比如我要做一個論壇、一個部落格系統、一個電商平臺、一個灰度釋出系統、一個IDE、一個分散式訊息佇列、一個通訊框架，等等。

DDD切入點1 - 理解概念

DDD的全稱為Domain-driven Design，即領域驅動設計。下面我從領域、問題域、領域模型、設計、驅動這幾個詞語的含義和聯絡的角度去闡述DDD是如何融入到我們平時的軟體開發初期階段的。要理解什麼是領域驅動設計，首先要理解什麼是領域，什麼是設計，還有驅動是什麼意思，什麼驅動什麼。

什麼是領域（Domain）？

前面我們已經清楚的知道我們現在要做一個什麼樣的系統，這個系統需要解決什麼問題。我認為任何一個系統都會屬於某個特定的領域，比如論壇是一個領域，只要你想做一個論壇，那這個論壇的核心業務是確定的，比如都有使用者發帖、回帖等核心基本功能。比如電商平臺、普通電商系統，這種都屬於網上電商領域，只要是這個領域的系統，那都有商品瀏覽、購物車、下單、減庫存、付款交易等核心環節。所以，同一個領域的系統都具有相同的核心業務，因為他們要解決的問題的本質是類似的。

因此，我們可以推斷出，一個領域本質上可以理解為就是一個問題域，只要是同一個領域，那問題域就相同。所以，只要我們確定了系統所屬的領域，那這個系統的核心業務，即要解決的關鍵問題、問題的範圍邊界就基本確定了。通常我們說，要成為一個領域的專家，必須要在這個領域深入研究很多年才行。因為只有你研究了很多年，你才會遇到非常多的該領域的問題，同時你解決這個領域中的問題的經驗也非常豐富。很多時候，領域專家比技術專家更加吃香，比如金融領域的專家。

什麼是設計（Design）？

DDD中的設計主要指領域模型的設計。為什麼是領域模型的設計而不是架構設計或其他的什麼設計呢？因為DDD是一種基於模型驅動開發的軟體開發思想，強調領域模型是整個系統的核心，領域模型也是整個系統的核心價值所在。每一個領域，都有一個對應的領域模型，領域模型能夠很好的幫我們解決複雜的業務問題。

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

什麼是驅動（Driven）？

上面其實已經提到了，就是：1）領域驅動領域模型設計；2）領域模型驅動程式碼實現。這個就和我們傳統的資料庫驅動開發的思路形成對比了。DDD中，我們總是以領域為邊界，分析領域中的核心問題（核心關注點），然後設計對應的領域模型，再通過領域模型驅動程式碼實現。而像資料庫設計、持久化技術等這些都不是DDD的核心，而是外圍的東西。

領域驅動設計（DDD）告訴我們的最大價值我覺得是：當我們要開發一個系統時，應該儘量先把領域模型想清楚，然後再開始動手編碼，這樣的系統後期才會很好維護。但是，很多專案（尤其是網際網路專案，為了趕工）都是一開始模型沒想清楚，一上來就開始建表寫程式碼，程式碼寫的非常冗餘，完全是過程是的思考方式，最後導致系統非常難以維護。而且更糟糕的是，出來混總是要還的，前期的領域模型設計的不好，不夠抽象，如果你的系統會長期需要維護和適應業務變化，那後面你一定會遇到各種問題維護上的困難，比如資料結構設計不合理，程式碼到處冗餘，改BUG到處引入新的BUG，新人對這種程式碼上手困難，等。而那時如果你再想重構模型，那要付出的代價會比一開始重新開發還要大，因為你還要考慮相容歷史的資料，資料遷移，如何平滑釋出等各種頭疼的問題。所以，就導致我們最後天天加班。

雖然，我們都知道這個道理，但是我也明白，人的習慣很難改變的，大部分人都很難從面向過程式的想到哪裡寫到哪裡的思想轉變為基於系統化的模型驅動的思維。我想，這或許是DDD很難在中國或國外流行起來的原因吧。但是，我想這不應該成為我們放棄學習DDD的原因，對吧！

概念總結：

1. 領域就是問題域，有邊界，領域中有很多問題；
2. 任何一個系統要解決的那個大問題都對應一個領域；
3. 通過建立領域模型來解決領域中的核心問題，模型驅動的思想；
4. 領域建模的目標針對我們在領域中所關心的問題，即只針對核心關注點，而不是整個領域中的所有問題；
5. 領域模型在設計時應考慮一定的抽象性、通用性，以及複用價值；
6. 通過領域模型驅動程式碼的實現，確保程式碼讓領域模型落地，程式碼最終能解決問題；
7. 領域模型是系統的核心，是領域內的業務的直接沉澱，具有非常大的業務價值；
8. 技術架構設計或資料儲存等是在領域模型的外圍，幫助領域模型進行落地；

DDD切入點2 - 理解領域、拆分領域、細化領域

理解領域知識是基礎

上面我們通過第一步，雖然我們明確了要做一個什麼樣的系統，該系統主要解決什麼問題，但是就這樣我們還無法開始進行實際的需求分析和模型設計，我們還必須將我們的問題進行拆分，需求進行細化。有些時候，需求方，即提出問題的人，很可能自己不清楚具體想要什麼。他只知道一個概念，一個大的目標。比如他只知道要做一個股票交易系統，一個灰度釋出系統，一個電商平臺，一個開發工具，等。但是他不清楚這些系統應該具體做成什麼樣子。這個時候，我認為領域專家就非常重要了，DDD也非常強調領域專家的重要性。因為領域專家對這個領域非常瞭解，對領域內的各種業務場景和各種業務規則也非常清楚，總之，對這個領域內的一切業務相關的知識都非常瞭解。所以，他們自然就有能力表達出系統該做成什麼樣子。所以，要知道一個系統到底該做成什麼樣子，到底哪些是核心業務關注點，只能靠沉澱領域內的各種知識，別無他法。因此，假設你現在打算做一個電商平臺，但是你對這個領域沒什麼瞭解，那你一定得先去了解下該領域內主流的電商平臺，比如淘寶、天貓、京東、亞馬遜等。這個瞭解的過程就是你沉澱領域知識的過程。如果你不瞭解，就算你領域建模的能力再強，各種技術架構能力再強也是使不上力。領域專家不是某個固定的角色，而是某一類人，這類人對這個領域非常瞭解。比如，一個開發人員也可以是一個領域專家。假設你在一個公司開發和維護一個系統已經好幾年了，但是這個系統的產品經理（PD）可能已經換過好幾任了，這種情況下，我相信這幾任產品經理都沒有比你更熟悉這個領域。

拆分領域

上面我們明白了，領域建模的基礎是要先理解領域，讓自己成為領域專家。如果做到了這點，我們就打好了堅實的基礎了。但是，有時一個領域往往太複雜，涉及到的領域概念、業務規則、互動流程太多，導致我們沒辦法直接針對這個大的領域進行領域建模。所以，我們需要將領域進行拆分，本質上就是把大問題拆分為小問題，然後各個擊破的思路。然後既然把一個大的領域劃分為了多個小的領域（子域），那最關鍵的就是要理清每個子域的邊界；然後要搞清楚哪些子域是核心子域，哪些是非核心子域，哪些是公共支撐子域；然後，還要思考子域之間的聯絡是什麼。那麼，我們該如何劃分子域呢？我的個人看法是從業務相關性的角度去思考，也就是我們平時說的按業務功能為出發點進行劃分。還是拿經典的電商系統來分析，通常一個電商系統都會包含好幾個大塊，比如：

• 會員中心：負責使用者賬號登入、使用者資訊的管理；
• 商品中心：負責商品的展示、導航、維護；
• 訂單中心：負責訂單的生成和生命週期管理；
• 交易中心：負責交易相關的業務；
• 庫存中心：負責維護商品的庫存；
• 促銷中心：負責各種促銷活動的支援；

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

細化子域

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

1. 梳理領域概念：梳理出領域內我們關注的概念、概念的關係，並統一交流詞彙，形成統一語言；
2. 梳理業務規則：梳理出領域內我們關注的各種業務規則，DDD中叫不變性（invariants），比如唯一性規則，餘額不能小於零等；
3. 梳理業務場景：梳理出領域內的核心業務場景，比如電商平臺中的加入購物車、提交訂單、發起付款等核心業務場景；
4. 梳理業務流程：梳理出領域內的關鍵業務流程，比如訂單處理流程，退款流程等；

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

關於領域概念的梳理，我覺得可以採用四色原型分析法，這個分析法通過系統的方法，將概念劃分為不同的種類，為不同種類的概念標註不同的顏色。然後將這些概念有機的組合起來，從而讓我們可以清晰的分析出概念和概念之間的關係。有興趣的同學可以在網上搜索下四色原型。

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

DDD切入點3 - 領域模型設計

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

關於這些建模工具的概念和如何運用我就不多展開了，我部落格裡也有很多這方面的介紹。下面我再講一下我認為比較重要的東西，比如到底該如何領域建模？步驟應該是怎麼樣的？

領域建模的方法

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

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

領域模型的核心作用：

1. 抽象了領域內的核心概念，並建立概念之間的關係；
2. 領域模型承擔了領域內的狀態的維護；
3. 領域模型維護了領域內的資料之間的業務規則，資料一致性；

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

領域模型設計只是軟體設計中的一小部分

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

• 容量規劃
• 架構設計
• 資料庫設計
• 快取設計
• 框架選型
• 釋出方案
• 資料遷移、同步方案
• 分庫分表方案
• 回滾方案
• 高併發解決方案
• 一致性選型
• 效能壓測方案
• 監控報警方案

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

總結

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