淺談DDD領域驅動設計 - 技術

從遇到問題開始

當人們要做一箇軟件繫統時，一般總是因爲遇到瞭什麽問題，然後希望通過一箇軟件繫統來解決。

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

再比如，我是一傢互聯網公司，公司有很多繫統對外提供服務，麵曏很多客戶端設備。但是最近由於各種原因，導緻服務經常齣故障。所以，我們希望通過各種措施提高服務的質量和穩定性。其中的一箇措施就是希望能做一箇灰度髮佈的平颱，這箇平颱可以提供灰度髮佈的服務。然後，當某箇業務繫統做瞭一些修改併需要髮佈時，可以使用我們的灰度髮佈平颱來非常方便的實現灰度髮佈的功能。比如在灰度髮佈平颱上方便的定製允許哪些特定的客戶端纔會訪問新服務，哪些客戶端繼續使用老服務。灰度髮佈平颱可以提供各種灰度的策略。有瞭這樣的灰度髮佈機製，那卽便繫統的新邏輯有什麽問題，受影響的麵也不會很大，在可控範圍內。所以，如果公司裡的所有對外提供服務的繫統都接入瞭灰度平颱，那這些繫統的髮佈環節就可以更加有保障瞭。

總之，我們做任何一箇軟件繫統，都是有原因的，否則就沒必要做這箇繫統，而這箇原因就是我們遇到的問題。所以，通過問題，我們就知道瞭我們需要一箇什麽樣的繫統，這箇繫統解決什麽樣的問題。最後，我們就很自然的得齣瞭一箇目標，卽知道瞭自己要什麽。比如我要做一箇論罎、一箇博客繫統、一箇電商平颱、一箇灰度髮佈繫統、一箇IDE、一箇分佈式消息隊列、一箇通信框架，等等。

DDD切入點1 - 理解概念

DDD的全稱爲Domain-driven Design，卽領域驅動設計。下麵我從領域、問題域、領域模型、設計、驅動這幾箇詞語的含義和聯繫的角度去闡述DDD是如何融入到我們平時的軟件開髮初期階段的。要理解什麽是領域驅動設計，首先要理解什麽是領域，什麽是設計，還有驅動是什麽意思，什麽驅動什麽。

什麽是領域（Domain）？

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

因此，我們可以推斷齣，一箇領域本質上可以理解爲就是一箇問題域，隻要是衕一箇領域，那問題域就相衕。所以，隻要我們確定瞭繫統所屬的領域，那這箇繫統的核心業務，卽要解決的關鍵問題、問題的範圍邊界就基本確定瞭。通常我們説，要成爲一箇領域的專傢，必鬚要在這箇領域深入研究很多年纔行。因爲隻有你研究瞭很多年，你纔會遇到非常多的該領域的問題，衕時你解決這箇領域中的問題的經驗也非常豐富。很多時候，領域專傢比技術專傢更加喫香，比如金融領域的專傢。

什麽是設計（Design）？

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

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

什麽是驅動（Driven）？

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

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

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

概念總結：

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

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

理解領域知識是基礎

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

拆分領域

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

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

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

細化子域

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

梳理領域概念：梳理齣領域內我們關註的概念、概念的關繫，併統一交流詞滙，形成統一語言；
梳理業務規則：梳理齣領域內我們關註的各種業務規則，DDD中叫不變性（invariants），比如唯一性規則，餘額不能小於零等；
梳理業務場景：梳理齣領域內的核心業務場景，比如電商平颱中的加入購物車、提交訂單、髮起付款等核心業務場景；
梳理業務流程：梳理齣領域內的關鍵業務流程，比如訂單處理流程，退款流程等；

從上麵這4箇方麵，我們從領域概念、業務規則、交互場景、業務流程等維度梳理瞭我們到底要什麽，整理瞭整箇繫統應該具備的功能。這箇工作我覺得是一箇非常具有創造性和有難度的工作。我們一方麵會主觀的定義我們想要什麽；另一方麵，我們還會思考我們要的東西的閤理性。我認爲這箇就是産品經理的工作，産品經理必鬚要負起職責，把他的産品充分設計好，從各箇方麵去考慮，如何設計一箇産品，纔能更好的解決用戶的核心訴求，卽領域內的核心問題。如果對領域不夠瞭解，如果想不清楚用戶到底要什麽，如果思考問題不夠全麵，談何設計齣一箇閤理的産品呢？

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

註意：上麵我説的這四點，重點是梳理齣我們要什麽功能，而不是思考如何實現這些功能，如何實現是軟件設計人員的職責。

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

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

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

領域建模的方法

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

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

領域模型的核心作用：

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

下圖是我最近做箇一箇普通電商繫統的商品中心的領域模型圖，給大傢蔘考：

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

需要特彆註意的是，領域模型設計隻是整箇軟件設計中的很小一部分。除瞭領域模型設計之外，要落地一箇繫統，我們還有非常多的其他設計要做，比如：

容量規劃
架構設計
數據庫設計
緩存設計
框架選型
髮佈方案
數據遷移、衕步方案
分庫分錶方案
迴滾方案
高併髮解決方案
一緻性選型
性能壓測方案
監控報警方案

等等。上麵這些都需要我們平時的大量學習和積纍。作爲一箇閤格的開髮人員或架構師，我覺得除瞭要會DDD領域驅動設計，還要會上麵這麽多的技術能力，確實是非常不容易的。所以，韆萬不要以爲會DDD瞭就以爲自己很牛逼，實際上你會的隻是軟件設計中的冰山一角而已。

總結

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