輕松學DDD之二：如何高效消化知識

我是2012年開始接觸DDD的，后續研讀過幾遍《領域驅動設計：軟件核心復雜性應對之道》，也用DDD做過項目。總的感受是DDD的一些概念比較晦澀難懂，很難掌握，因此想寫個系列短文，希望能幫助大家更輕松地理解DDD。文章很多都是我個人體會和理解，難免有錯誤，希望大家能及時指正，共同探討提高。前面短文鏈接：

輕松學DDD之一：模型驅動設計

本文是系列短文第二篇，介紹如何高效消化知識。

1. 知識來源

在講如何消化知識前，我們要明確下建模的知識來源有哪些。首先我們通過下圖來考察模型、領域、軟件、現實世界、計算機系統等幾個概念的關聯。

1\現實世界(藍線左半邊）和計算機系統（藍線右半邊）。我們把用戶需求理解為用戶要求我們構建一個特定的計算機系統，通過它用戶能按自己的期望來改變現實世界。比如淘寶網就是一個這樣的計算機系統，通過它阿里巴巴可以讓商品銷售變得更快捷、更方便、成本更低。

2\領域和軟件。領域就是用戶需求和從用戶需求這個視角出發對現實世界的認知集合；軟件就是可以讓計算機系統按照用戶期望方式來運轉的程序。

3\領域模型。它富含領域知識，與實現綁定，能夠把領域和軟件有效地耦合起來，從而能夠讓我們基于模型快速開發功能豐富的軟件產品。

從上面的認知我們可以知道模型就是在用戶目標和軟件實現技術的約束下對領域知識的精確化、結構化和抽象。

2. 知識消化

由于建模依賴于在用戶目標和軟件實現技術約束下的領域知識梳理，因此建模就要求領域專家、建模專家和軟件開發之間通過高效地溝通協作來有效地消化領域知識。下面我們從溝通媒介、溝通形式和目標三個方面來展開說明如何做到這一點。

2.1 溝通媒介

消化知識的溝通媒介可以是多種多樣，下面是幾種主要的溝通媒介：

口語：這是人類最擅長的溝通方式，成本低廉，形式豐富，是eric最為推崇的溝通手段。

文字：擅長精確表達，同時與口語的轉換也非常方便。我們用文字來記錄模型中最重要的概念、行為、規則的定義和解釋。

UML：圖形形式的UML非常擅長表達對象間的關系和交互，也能有效地指導OO語言的代碼編寫。但是它不擅長概念的定義，也難以表達對象的行為和約束，需要與文字說明配合。UML圖包含了大量的實現細節，大家很難基于它們做高效溝通，同時創建維護它們需要大量的工作量，因此我們往往用簡單的非正式的UML圖作為討論的主題。

代碼：通過代碼表達業務細節可以讓我們節省大量的文檔編寫維護的工作量；同時如果代碼能夠讓領域專家容易理解乃至編寫，也可以讓模型能更好地與實現綁定。但是代碼往往充斥實現細節，難以表達整體的、大比例的模型知識。

解釋性模型：用戶驅動軟件開發過程的技術模型必須經過嚴格的精簡，受到嚴格的限制，因此基于技術模型學習領域知識效率很低。解釋性模型則沒有這些限制，用它可以更快更好地理解領域知識。

總體來講，我們應該以口語為主要溝通手段，用文字定義重要的領域對象、約束和行為，用簡化的非正式UML圖表達領域對象間的關聯和交互，用代碼來承載設計細節，用解釋性模型來加快領域知識的學習。

2.2.知識消化的溝通形式

有了溝通手段，我們還需要溝通形式，下面是一些主要的溝通形式：

頭腦風暴。當一群人圍繞一個特定的興趣領域產生新觀點的時候，這種情境就叫做頭腦風暴。頭腦風暴通過參與者之間充分的思想碰撞來激發新觀點和解決方法，因此非常適合在建模初期使用。頭腦風暴具體展開形式我們可以采用以簡化的UML圖為主題，一邊討論一邊精煉的方式；也可以采用現在比較流行的事件風暴方式。

場景走查。我們可以基于模型來走查各種場景，以便確認模型能夠很好地表達和實現各種場景。場景走查是一個成本低廉的試錯手段，通過它我們可以避免由于不合理的模型造成軟件開發的返工。

原型反饋。當建模有初步成果時，開發可以基于現有模型快速實現一個沒有界面和持久化數據庫的原型，以驗證模型的有效性，同時基于原型可以更加直觀地與領域專家做進一步溝通。

建模專家與開發結對編碼。建模專家可以通過與開發的結對編碼，可以更加全面地收集模型映射為代碼的過程中的各種碰到的問題，這樣能更好地識別和修正模型中存在的缺陷。

小范圍討論。當模型初步穩定后，模型仍會根據需求變化以及理解的加深不斷演進，此時團隊中已經有若干能深刻理解模型的骨干，因此對于模型的局部修改，與他們一起做小范圍討論會更加高效。變化的結果可以通過各種方式通知給團隊的全體成員。

2.3. 目標

知識消化的最終目標無疑是構建良好的模型，但是構建良好的模型需要通過統一語言和精煉模型來支撐。

2.3.1. 統一語言

統一語言是指團隊所有成員用統一的術語來指代領域概念和知識，它有如下幾方面：

統一的術語。這個可以說是統一語言的起點。

術語是精確的。確保術語是精確地指代一個領域概念和知識。當術語的含義模糊、含義過于寬泛、在不同上下文下有不同含義等情況時，往往會造成大家理解上的偏差，最終統一只淪落為形式上的。

術語理解不需要翻譯。團隊有些成員或者角色（比如開發）在理解術語時，會在頭腦中把它翻譯為另一個更容易理解的術語再來理解。如果有這種情況，請把頭腦中的術語也表達出來，大家要重新看看哪個術語能更好地表達領域知識。

統一口語、文檔和UML等各種形式的語言。同樣一個概念不管在口語、文檔描述還是UML圖中都應該統一起來，否則也容易造成理解偏差。如果有些術語不能郎朗上口，那么就修改為一個可以郎朗上口的術語。

2.3.2 模型精煉

我們知道簡單合理的軟件設計是軟件在長期的開發過程中能夠保持低成本修改的關鍵。在DDD中，領域模型的復雜度決定了軟件設計的復雜度，因此模型精煉就是我們消化領域知識的最重要的目標。也就是說我們消化領域知識的目標不是為了理解全部的領域知識；而是為了明確對于實現用戶需求而言，哪些領域知識是重要的，哪些是不重要的。模型精煉是一個持續的過程。隨著我們對于領域理解的不斷深入，模型會持續精煉。隨著需求的不斷變化，模型關注的最重要的概念也會不斷添加和刪除。

3. 知識傳承

消化知識是如此之難，因此保證這些知識的平穩傳承就很重要。盡管這些知識會沉淀在我們的文檔、UML和代碼等各種物質載體之中，但是它們最重要的載體還是團隊中深刻理解了這些知識的核心骨干，因此在軟件開發過程中保證這些核心骨干的相對穩定才能保證知識的有效傳承，才能最終保證DDD的成功。

-----------------------

本文轉自鄔領東博客51CTO博客

如需轉載，請聯系授權

UML 專家

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。