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

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

　　我是2012年開始接觸DDD的，後續研讀過幾遍《領域驅動設計：軟件核心複雜性應對之道》，也用DDD作過項目。總的感覺是DDD的一些概念比較晦澀難懂，很難掌握，所以想寫個系列短文，但願能幫助你們更輕鬆地理解DDD。文章不少都是我我的體會和理解，不免有錯誤，但願你們能及時指正，共同探討提升。前面短文連接：
　　輕鬆學DDD之一：模型驅動設計
　　本文是系列短文第二篇，介紹如何高效消化知識。
　　
　

1. 知識來源

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

1. 現實世界(藍線左半邊）和計算機系統（藍線右半邊）。咱們把用戶需求理解爲用戶要求咱們構建一個特定的計算機系統，經過它用戶能按本身的指望來改變現實世界。好比淘寶網就是一個這樣的計算機系統，經過它阿里巴巴可讓商品銷售變得更快捷、更方便、成本更低。
2. 領域和軟件。領域就是用戶需求和從用戶需求這個視角出發對現實世界的認知集合；軟件就是可讓計算機系統按照用戶指望方式來運轉的程序。
3. 領域模型。它富含領域知識，與實現綁定，可以把領域和軟件有效地耦合起來，從而可以讓咱們基於模型快速開發功能豐富的軟件產品。

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

2. 知識消化

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

2.1 溝通媒介

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

1. 口語：這是人類最擅長的溝通方式，成本低廉，形式豐富，是eric最爲推崇的溝通手段。
2. 文字：擅長精確表達，同時與口語的轉換也很是方便。咱們用文字來記錄模型中最重要的概念、行爲、規則的定義和解釋。
3. UML：圖形形式的UML很是擅長表達對象間的關係和交互，也能有效地指導OO語言的代碼編寫。可是它不擅長概念的定義，也難以表達對象的行爲和約束，須要與文字說明配合。UML圖包含了大量的實現細節，你們很難基於它們作高效溝通，同時建立維護它們須要大量的工做量，所以咱們每每用簡單的非正式的UML圖做爲討論的主題。
4. 代碼：經過代碼表達業務細節可讓咱們節省大量的文檔編寫維護的工做量；同時若是代碼可以讓領域專家容易理解乃至編寫，也可讓模型能更好地與實現綁定。可是代碼每每充斥實現細節，難以表達總體的、大比例的模型知識。
5. 解釋性模型：用戶驅動軟件開發過程的技術模型必須通過嚴格的精簡，受到嚴格的限制，所以基於技術模型學習領域知識效率很低。解釋性模型則沒有這些限制，用它能夠更快更好地理解領域知識。
   　　整體來說，咱們應該以口語爲主要溝通手段，用文字定義重要的領域對象、約束和行爲，用簡化的非正式UML圖表達領域對象間的關聯和交互，用代碼來承載設計細節，用解釋性模型來加快領域知識的學習。

2.2.知識消化的溝通形式

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

1. 頭腦風暴。當一羣人圍繞一個特定的興趣領域產生新觀點的時候，這種情境就叫作頭腦風暴。頭腦風暴經過參與者之間充分的思想碰撞來激發新觀點和解決方法，所以很是適合在建模初期使用。頭腦風暴具體展開形式咱們能夠採用以簡化的UML圖爲主題，一邊討論一邊精煉的方式；也能夠採用如今比較流行的事件風暴方式。
2. 場景走查。咱們能夠基於模型來走查各類場景，以便確認模型可以很好地表達和實現各類場景。場景走查是一個成本低廉的試錯手段，經過它咱們能夠避免因爲不合理的模型形成軟件開發的返工。
3. 原型反饋。當建模有初步成果時，開發能夠基於現有模型快速實現一個沒有界面和持久化數據庫的原型，以驗證模型的有效性，同時基於原型能夠更加直觀地與領域專家作進一步溝通。
4. 建模專家與開發結對編碼。建模專家能夠經過與開發的結對編碼，能夠更加全面地收集模型映射爲代碼的過程當中的各類碰到的問題，這樣能更好地識別和修正模型中存在的缺陷。
5. 小範圍討論。當模型初步穩定後，模型仍會根據需求變化以及理解的加深不斷演進，此時團隊中已經有若干能深入理解模型的骨幹，所以對於模型的局部修改，與他們一塊兒作小範圍討論會更加高效。變化的結果能夠經過各類方式通知給團隊的全體成員。

2.3. 目標

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

2.3.1. 統一語言

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

1. 統一的術語。這個能夠說是統一語言的起點。
2. 術語是精確的。確保術語是精確地指代一個領域概念和知識。當術語的含義模糊、含義過於寬泛、在不一樣上下文下有不一樣含義等狀況時，每每會形成你們理解上的誤差，最終統一隻淪落爲形式上的。
3. 術語理解不須要翻譯。團隊有些成員或者角色（好比開發）在理解術語時，會在頭腦中把它翻譯爲另外一個更容易理解的術語再來理解。若是有這種狀況，請把頭腦中的術語也表達出來，你們要從新看看哪一個術語能更好地表達領域知識。
4. 統一口語、文檔和UML等各類形式的語言。一樣一個概念無論在口語、文檔描述仍是UML圖中都應該統一塊兒來，不然也容易形成理解誤差。若是有些術語不能郎朗上口，那麼就修改成一個能夠郎朗上口的術語。

2.3.2 模型精煉

咱們知道簡單合理的軟件設計是軟件在長期的開發過程當中可以保持低成本修改的關鍵。在DDD中，領域模型的複雜度決定了軟件設計的複雜度，所以模型精煉就是咱們消化領域知識的最重要的目標。也就是說咱們消化領域知識的目標不是爲了理解所有的領域知識；而是爲了明確對於實現用戶需求而言，哪些領域知識是重要的，哪些是不重要的。模型精煉是一個持續的過程。隨着咱們對於領域理解的不斷深刻，模型會持續精煉。隨着需求的不斷變化，模型關注的最重要的概念也會不斷添加和刪除。

3. 知識傳承

消化知識是如此之難，所以保證這些知識的平穩傳承就很重要。儘管這些知識會沉澱在咱們的文檔、UML和代碼等各類物質載體之中，可是它們最重要的載體仍是團隊中深入理解了這些知識的核心骨幹，所以在軟件開發過程當中保證這些核心骨幹的相對穩定才能保證知識的有效傳承，才能最終保證DDD的成功。