淺談領域驅動設計（DDD）

從遇到問題開始

當人們要做一個軟件系統時，一般總是因爲遇到了什麼問題，然後希望通過一個軟件系統來解決。比如，我是一家企業，然後我覺得目前線下銷售產品還不夠，希望能夠在線上也能進行產品銷售，所以理所當然的想到要做一個普通的電商系統，用於實現在線銷售自己企業產品的目的。再比如，我是一家互聯網公司，公司裏邊有很多系統對外提供服務，面向很多客戶端設備，但是由於各種原因，導致服務經常出故障。所以，我們希望通過各種措施提高服務的質量和穩定性。那麼其中一個措施就是希望能做一個灰度發佈的平臺，可以提供灰度發佈的服務。然後，當某個業務系統做了一些修改並需要發佈時，可以使用我們的灰度發佈平臺來非常方便的實現灰度發佈的功能，比如在灰度發佈平臺上方便的定製允許哪些特定的客戶端纔會訪問新服務，哪些客戶端繼續使用老服務。灰度發佈平臺可以提供各種灰度的策略。有了這樣的灰度發佈機制，那即便系統的新邏輯有什麼問題，受影響的面也不會很大，在可控範圍內。所以，如果公司裏的所有對外提供服務的系統都接入了灰度平臺，那這些系統的發佈環節就可以更加有保障了。

總之，我們做任何一個軟件系統，都是有原因的，否則就沒有必要做這個系統，而這個原因就是我們遇到的問題。所以，通過問題，我們就知道了我們需要一個什麼樣的系統，這個系統解決什麼樣的問題。最後，我們就很自然的得出了一個目標，即知道了自己要什麼。bi ru 我要做一個匿名論壇、一個分佈式博客系統、一個電商平臺、一個灰度發佈系統、一個分佈式消息隊列、一個通信框架，等等。

DDD 切入點 1 - 理解概念

DDD 全稱是 Domain Driven Design，即領域驅動設計。下面從領域、問題域、領域建模、設計、驅動這幾個詞語的含義和聯繫的角度去闡述 DDD 是如何融入到平時的軟件開發初期階段的。要理解什麼是領域驅動設計，首先要理解什麼是領域，什麼是設計，還有什麼是驅動，到底是什麼在驅動什麼。

什麼是領域（Domain）？

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

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

什麼是設計（Design）？

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

從領域和代碼實現的角度來理解，領域模型綁定了領域和代碼實現，確保了最終的代碼實現就一定是解決了領域中的核心問題的。因爲：

領域驅動領域模型設計；
領域模型驅動代碼實現。

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

什麼是驅動（Driven）？

其實上面已經提到了，也就是：

領域驅動領域模型設計；
領域模型驅動代碼實現。

這個就和傳統的數據庫驅動開發的思路形成鮮明對比了。DDD 中，總是以領域爲邊界，分析領域中的核心問題（核心關注點），然後設計對應的領域模型，再通過領域模型驅動代碼實現。而像數據庫設計、持久化技術等這些都不是 DDD 的核心，而是外圍的東西。

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

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

概念總結：

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

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

理解領域知識是基礎

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

拆分領域

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

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

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

細化子域

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

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

以上幾點，從領域概念、業務規劃、交互場景、業務流程等維度梳理了到底要什麼，整理了整個系統應該具備的功能，這是一個非常具有創造性和有難度的工作。一方面會主觀的定義想要什麼；另一方面，還會思考要的東西的合理性。我認爲這個就是產品經理的工作，產品經理必須要負起職責，把他的產品充分設計好，從各個方面去考慮，如何設計一個產品，才能更好的解決用戶的核心訴求，即領域內的核心問題。如果對領域不夠了解，如果想不清楚用戶到底要什麼，如果考慮問題不夠全面，談何設計出一個合理的產品呢？關於領域概念的梳理，可以採用四色原型分析法，通過系統的方法，將概念劃分爲不同的種類，爲不同種類的概念標註不同顏色，然後將這些概念有機的組合起來，從而可以清楚的分析出概念和概念之間的關係。

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

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

領域建模的方法

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

領域模型的核心作用：

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

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

要落地一個系統，除了領域模型設計之外，還有非常多的其他設計要做：

架構設計
數據庫設計
框架選型
高併發解決方案
緩存設計
回滾方案
一致性選型
監控報警方案
...

總結

本文是個人近期學習以及對 DDD 的一些理解，同時也參考了其他大牛對於 DDD 的見解，梳理彙總總結出來，分享給各位看官，歡迎各位分享不同的見解，一起交流。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/uaMZxV4cnmsiMObhJF0yyQ

猜你喜歡