輕松學(xué)DDD之二：如何高效消化知識

輕松學(xué)DDD之二：如何高效消化知識

　　我是2012年開始接觸DDD的，后續(xù)研讀過幾遍《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)：軟件核心復(fù)雜性應(yīng)對之道》，也用DDD做過項(xiàng)目?？偟母惺苁荄DD的一些概念比較晦澀難懂，很難掌握，因此想寫個(gè)系列短文，希望能幫助大家更輕松地理解DDD。文章很多都是我個(gè)人體會(huì)和理解，難免有錯(cuò)誤，希望大家能及時(shí)指正，共同探討提高。前面短文鏈接：
　　輕松學(xué)DDD之一：模型驅(qū)動(dòng)設(shè)計(jì)
　　本文是系列短文第二篇，介紹如何高效消化知識。
　　
　

1. 知識來源

在講如何消化知識前，我們要明確下建模的知識來源有哪些。首先我們通過下圖來考察模型、領(lǐng)域、軟件、現(xiàn)實(shí)世界、計(jì)算機(jī)系統(tǒng)等幾個(gè)概念的關(guān)聯(lián)。

1. 現(xiàn)實(shí)世界(藍(lán)線左半邊）和計(jì)算機(jī)系統(tǒng)（藍(lán)線右半邊）。我們把用戶需求理解為用戶要求我們構(gòu)建一個(gè)特定的計(jì)算機(jī)系統(tǒng)，通過它用戶能按自己的期望來改變現(xiàn)實(shí)世界。比如淘寶網(wǎng)就是一個(gè)這樣的計(jì)算機(jī)系統(tǒng)，通過它阿里巴巴可以讓商品銷售變得更快捷、更方便、成本更低。
2. 領(lǐng)域和軟件。領(lǐng)域就是用戶需求和從用戶需求這個(gè)視角出發(fā)對現(xiàn)實(shí)世界的認(rèn)知集合；軟件就是可以讓計(jì)算機(jī)系統(tǒng)按照用戶期望方式來運(yùn)轉(zhuǎn)的程序。
3. 領(lǐng)域模型。它富含領(lǐng)域知識，與實(shí)現(xiàn)綁定，能夠把領(lǐng)域和軟件有效地耦合起來，從而能夠讓我們基于模型快速開發(fā)功能豐富的軟件產(chǎn)品。

從上面的認(rèn)知我們可以知道模型就是在用戶目標(biāo)和軟件實(shí)現(xiàn)技術(shù)的約束下對領(lǐng)域知識的精確化、結(jié)構(gòu)化和抽象。

2. 知識消化

　　由于建模依賴于在用戶目標(biāo)和軟件實(shí)現(xiàn)技術(shù)約束下的領(lǐng)域知識梳理，因此建模就要求領(lǐng)域?qū)＜摇⒔＜液蛙浖_發(fā)之間通過高效地溝通協(xié)作來有效地消化領(lǐng)域知識。下面我們從溝通媒介、溝通形式和目標(biāo)三個(gè)方面來展開說明如何做到這一點(diǎn)。

2.1 溝通媒介

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

1. 口語：這是人類最擅長的溝通方式，成本低廉，形式豐富，是eric最為推崇的溝通手段。
2. 文字：擅長精確表達(dá)，同時(shí)與口語的轉(zhuǎn)換也非常方便。我們用文字來記錄模型中最重要的概念、行為、規(guī)則的定義和解釋。
3. UML：圖形形式的UML非常擅長表達(dá)對象間的關(guān)系和交互，也能有效地指導(dǎo)OO語言的代碼編寫。但是它不擅長概念的定義，也難以表達(dá)對象的行為和約束，需要與文字說明配合。UML圖包含了大量的實(shí)現(xiàn)細(xì)節(jié)，大家很難基于它們做高效溝通，同時(shí)創(chuàng)建維護(hù)它們需要大量的工作量，因此我們往往用簡單的非正式的UML圖作為討論的主題。
4. 代碼：通過代碼表達(dá)業(yè)務(wù)細(xì)節(jié)可以讓我們節(jié)省大量的文檔編寫維護(hù)的工作量；同時(shí)如果代碼能夠讓領(lǐng)域?qū)＜胰菀桌斫饽酥辆帉?，也可以讓模型能更好地與實(shí)現(xiàn)綁定。但是代碼往往充斥實(shí)現(xiàn)細(xì)節(jié)，難以表達(dá)整體的、大比例的模型知識。
5. 解釋性模型：用戶驅(qū)動(dòng)軟件開發(fā)過程的技術(shù)模型必須經(jīng)過嚴(yán)格的精簡，受到嚴(yán)格的限制，因此基于技術(shù)模型學(xué)習(xí)領(lǐng)域知識效率很低。解釋性模型則沒有這些限制，用它可以更快更好地理解領(lǐng)域知識。
   　　總體來講，我們應(yīng)該以口語為主要溝通手段，用文字定義重要的領(lǐng)域?qū)ο?、約束和行為，用簡化的非正式UML圖表達(dá)領(lǐng)域?qū)ο箝g的關(guān)聯(lián)和交互，用代碼來承載設(shè)計(jì)細(xì)節(jié)，用解釋性模型來加快領(lǐng)域知識的學(xué)習(xí)。

2.2.知識消化的溝通形式

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

1. 頭腦風(fēng)暴。當(dāng)一群人圍繞一個(gè)特定的興趣領(lǐng)域產(chǎn)生新觀點(diǎn)的時(shí)候，這種情境就叫做頭腦風(fēng)暴。頭腦風(fēng)暴通過參與者之間充分的思想碰撞來激發(fā)新觀點(diǎn)和解決方法，因此非常適合在建模初期使用。頭腦風(fēng)暴具體展開形式我們可以采用以簡化的UML圖為主題，一邊討論一邊精煉的方式；也可以采用現(xiàn)在比較流行的事件風(fēng)暴方式。
2. 場景走查。我們可以基于模型來走查各種場景，以便確認(rèn)模型能夠很好地表達(dá)和實(shí)現(xiàn)各種場景。場景走查是一個(gè)成本低廉的試錯(cuò)手段，通過它我們可以避免由于不合理的模型造成軟件開發(fā)的返工。
3. 原型反饋。當(dāng)建模有初步成果時(shí)，開發(fā)可以基于現(xiàn)有模型快速實(shí)現(xiàn)一個(gè)沒有界面和持久化數(shù)據(jù)庫的原型，以驗(yàn)證模型的有效性，同時(shí)基于原型可以更加直觀地與領(lǐng)域?qū)＜易鲞M(jìn)一步溝通。
4. 建模專家與開發(fā)結(jié)對編碼。建模專家可以通過與開發(fā)的結(jié)對編碼，可以更加全面地收集模型映射為代碼的過程中的各種碰到的問題，這樣能更好地識別和修正模型中存在的缺陷。
5. 小范圍討論。當(dāng)模型初步穩(wěn)定后，模型仍會(huì)根據(jù)需求變化以及理解的加深不斷演進(jìn)，此時(shí)團(tuán)隊(duì)中已經(jīng)有若干能深刻理解模型的骨干，因此對于模型的局部修改，與他們一起做小范圍討論會(huì)更加高效。變化的結(jié)果可以通過各種方式通知給團(tuán)隊(duì)的全體成員。

2.3. 目標(biāo)

知識消化的最終目標(biāo)無疑是構(gòu)建良好的模型，但是構(gòu)建良好的模型需要通過統(tǒng)一語言和精煉模型來支撐。

2.3.1. 統(tǒng)一語言

統(tǒng)一語言是指團(tuán)隊(duì)所有成員用統(tǒng)一的術(shù)語來指代領(lǐng)域概念和知識，它有如下幾方面：

1. 統(tǒng)一的術(shù)語。這個(gè)可以說是統(tǒng)一語言的起點(diǎn)。
2. 術(shù)語是精確的。確保術(shù)語是精確地指代一個(gè)領(lǐng)域概念和知識。當(dāng)術(shù)語的含義模糊、含義過于寬泛、在不同上下文下有不同含義等情況時(shí)，往往會(huì)造成大家理解上的偏差，最終統(tǒng)一只淪落為形式上的。
3. 術(shù)語理解不需要翻譯。團(tuán)隊(duì)有些成員或者角色（比如開發(fā)）在理解術(shù)語時(shí)，會(huì)在頭腦中把它翻譯為另一個(gè)更容易理解的術(shù)語再來理解。如果有這種情況，請把頭腦中的術(shù)語也表達(dá)出來，大家要重新看看哪個(gè)術(shù)語能更好地表達(dá)領(lǐng)域知識。
4. 統(tǒng)一口語、文檔和UML等各種形式的語言。同樣一個(gè)概念不管在口語、文檔描述還是UML圖中都應(yīng)該統(tǒng)一起來，否則也容易造成理解偏差。如果有些術(shù)語不能郎朗上口，那么就修改為一個(gè)可以郎朗上口的術(shù)語。

2.3.2 模型精煉

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

3. 知識傳承

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