淺談我對DDD領域驅動設計的了解

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

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

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

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

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

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

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

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

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

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

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

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

領域就是問題域，有邊界，領域中有很多問題；

任何一個系統要解決的那個大問題都對應一個領域；

通過建立領域模型來解決領域中的核心問題，模型驅動的思想；

領域模組化的目标針對我們在領域中所關心的問題，即隻針對核心關注點，而不是整個領域中的所有問題；

領域模型在設計時應考慮一定的抽象性、通用性，以及複用價值；

通過領域模型驅動代碼的實作，確定代碼讓領域模型落地，代碼最終能解決問題；

領域模型是系統的核心，是領域内的業務的直接沉澱，具有非常大的業務價值；

技術架構設計或資料存儲等是在領域模型的外圍，幫助領域模型進行落地；

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

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

會員中心：負責使用者賬号登入、使用者資訊的管理；

商品中心：負責商品的展示、導航、維護；

訂單中心：負責訂單的生成和生命周期管理；

交易中心：負責交易相關的業務；

庫存中心：負責維護商品的庫存；

促銷中心：負責各種促銷活動的支援；

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

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

梳理領域概念：梳理出領域内我們關注的概念、概念的關系，并統一交流詞彙，形成統一語言；

梳理業務規則：梳理出領域内我們關注的各種業務規則，ddd中叫不變性（invariants），比如唯一性規則，餘額不能小于零等；

梳理業務場景：梳理出領域内的核心業務場景，比如電商平台中的加入購物車、送出訂單、發起付款等核心業務場景；

梳理業務流程：梳理出領域内的關鍵業務流程，比如訂單處理流程，退款流程等；

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

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

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

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

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

劃分好邊界上下文，通常每個子域（sub domain）對應一個邊界上下文（bounded context），同一個邊界上下文中的概念是明确的，沒有任何歧義；

畫出領域模型圖，圈出每個模型中的聚合邊界；

設計領域模型時，要考慮該領域模型是否滿足業務規則，同時還要綜合考慮技術實作等問題，比如并發問題；領域模型不是概念模型，概念模型不關注技術實作，領域模型關心；是以領域模型才能直接指導編碼實作；

思考領域模型是如何在業務場景中發揮作用的，以及是如何參與到業務流程的每個環節的；

場景走查，确認領域模型是否能滿足領域中的業務場景和業務流程；

模型持續重構、完善、精煉；

抽象了領域内的核心概念，并建立概念之間的關系；

領域模型承擔了領域内的狀态的維護；

領域模型維護了領域内的資料之間的業務規則，資料一緻性；

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

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

容量規劃

架構設計

資料庫設計

緩存設計

架構選型

釋出方案

資料遷移、同步方案

分庫分表方案

復原方案

高并發解決方案

一緻性選型

性能壓測方案

監控報警方案

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

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