《領域驅動設計：軟體核心複雜性應對之道（修訂版）》—第1章 1.2節知識消化

本節書摘來自異步社群《領域驅動設計：軟體核心複雜性應對之道（修訂版）》一書中的第1章，第1.2節知識消化，作者【美】埃裡克•埃文斯（eric evans）, 馬利偉 , 萬龍，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

1.2　知識消化

金融分析師要消化了解的内容是數字。他們篩選大量的詳細數字，對其進行組合和重組以便尋求潛在的意義，查找可以産生重要影響的簡單表示方式——一種可用作金融決策基礎的了解。

高效的領域模組化人員是知識的消化者。他們在大量資訊中探尋有用的部分。他們不斷嘗試各種資訊組織方式，努力尋找對大量資訊有意義的簡單視圖。很多模型在嘗試後被放棄或改造。隻有找到一組适用于所有細節的抽象概念後，工作才算成功。這一精華嚴謹地表示了所發現的最為相關的知識。

13

知識消化并非一項孤立的活動，它一般是在開發人員的上司下，由開發人員與領域專家組成的團隊來共同協作。他們共同收集資訊，并通過消化而将它組織為有用的形式。資訊的原始資料來自領域專家頭腦中的知識、現有系統的使用者，以及技術團隊以前在相關遺留系統或同領域的其他項目中積累的經驗。資訊的形式也多種多樣，有可能是為項目編寫的文檔，有可能是業務中使用的檔案，也有可能來自大量的讨論。早期版本或原型将經驗回報給團隊，然後團隊對一些解釋做出修改。

在傳統的瀑布方法中，業務專家與分析員進行讨論，分析員消化了解這些知識後，對其進行抽象并将結果傳遞給程式員，再由程式員編寫軟體代碼。由于這種方法完全沒有回報，是以總是失敗。分析員全權負責建立模型，但他們建立的模型隻是基于業務專家的意見。他們既沒有向程式員學習的機會，也得不到早期軟體版本的經驗。知識隻是朝一個方向流動，而且不會累積。

有些項目使用了疊代過程，但由于沒有對知識進行抽象而無法建立起知識體系。開發人員聽專家們描述某項所需的特性，然後開始建構它。他們将結果展示給專家，并詢問接下來做什麼。如果程式員願意進行重構，則能夠保持軟體足夠整潔，以便繼續擴充它；但如果程式員對領域不感興趣，則他們隻會了解程式應該執行的功能，而不去了解它背後的原理。雖然這樣也能開發出可用的軟體，但項目永遠也不會從原有特性中自然地擴充出強大的新特性。

好的程式員會自然而然地抽象并開發出一個可以完成更多工作的模型。但如果在模組化時隻是技術人員唱獨角戲，而沒有領域專家的協作，那麼得到的概念将是很幼稚的。使用這些膚淺知識開發出來的軟體隻能做基本工作，而無法充分反映出領域專家的思考方式。

14

在團隊所有成員一起消化了解模型的過程中，他們之間的互動也會發生變化。領域模型的不斷精化迫使開發人員學習重要的業務原理，而不是機械地進行功能開發。領域專家被迫提煉自己已知道的重要知識的過程往往也是完善其自身了解的過程，而且他們會漸漸了解軟體項目所必需的概念嚴謹性。

所有這些因素都促使團隊成員成為更合格的知識消化者。他們對知識去粗取精。他們将模型重塑為更有用的形式。由于分析員和程式員将自己的知識輸入到了模型中，是以模型的組織更嚴密，抽象也更為整潔，進而為實作提供了更大支援。同時，由于領域專家也将他們的知識輸入到了模型中，是以模型反映了業務的深層次知識，而且真正的業務原則得以抽象。

模型在不斷改進的同時，也成為組織項目資訊流的工具。模型聚焦于需求分析。它與程式設計和設計緊密互動。它通過良性循環加深團隊成員對領域的了解，使他們更透徹地了解模型，并對其進一步精化。模型永遠都不會是完美的，因為它是一個不斷演化完善的過程。模型對了解領域必須是切實可用的。它們必須非常精确，以便使應用程式易于實作和了解。