領域模型（一）

概述

每個軟體程式是為了執行使用者的某項活動，或是滿足使用者的某種需求。這些使用者應用軟體的問題區域就是軟體的領域。

為了建立真正能為使用者活動所用的軟體，開發團隊必須運用一整套與這些活動有關的知識體系。所需的知識廣度可能令人望而生畏，龐大而複雜的資訊也可能超乎想象。模型正是解決此類資訊超載問題的工具。模型這種知識形式對知識進行了選擇性的簡化和有意的結構化。

領域模型并非是某種特殊的圖，而是這種圖所要傳達的思想。它不單單是領域專家頭腦中的知識，而是對這類知識嚴格的組織且有選擇的抽象。圖可以表達和傳達一種模型，同樣，精心書寫的代碼或文字也能達到同樣的目的。

模型在領域驅動設計中的作用

在領域驅動設計中，3個基本用途決定了模型的選擇。

1. 模型和設計的核心互相影響。確定我們在模型中所進行的分析能夠轉化為最終産品。可以基于對模型的了解來解釋代碼。
2. 模型是團隊所有成員使用的用用語言的中樞。開發人員可以使用該語言來讨論程式。可以在無需翻譯的情況下與領域專家進行溝通。
3. 模型是濃縮的知識。模型是團隊一緻認同的領域知識的組織方式和重要元素的區分方式。透過我們如何選擇屬于、分解概念以及将概念聯系起來，模型記錄了我們看待領域的方式。

軟體的核心

軟體的核心是其為使用者解決領域相關的問題的能力。

在一個團隊中，對領域深層次了解的模型開發有時也會迷失方向，此時，了解領域核心的上司者能夠将軟體項目帶回到正确的軌道上來。

開發人員可以采用一些系統性的思考方法來透徹了解領域并開發出有效的模型。還有一些設計技巧可以使毫無頭緒的軟體應用變得井井有條。

有效模組化的要素

1. 模型和實作的綁定。
2. 建立一種基于模型的語言。

3. 開發一個蘊含豐富知識的模型。

   對象具有行為和強制性規則。模型并不僅僅是一種資料模式，它還是解決複雜問題不可或缺的部分。模型包含各種類型的知識。

4. 提煉模型。

   在模型日趨完善的過程中，重要的概念不斷被添加在模型中，但同樣重要的是，不再使用的或不重要的概念則從模型被移除。當一個不需要的概念與一個需要的概念有關聯時，則把重要的概念提取到一個新模型中，其他那些不要的概念就可以丢棄了。

5. 交流和實驗。

   語言和草圖，再加入交流，将與需求方的溝通變成“模型實驗室”，在這些讨論中可以示範、嘗試和判斷上百種變化。當團隊在分步讨論場景時，口頭表達本身就可以作為所提議的模型的可行性測試。

正是交流和大量的實驗的創造力才使團隊找到一個富含知識的模型并對它進行提煉，在這個過程中，基于模型的語言提供了很大幫助，而且貫穿整個實作過程中的回報閉環也對模型起到了“訓練”作用。這種 知識消化将團隊的知識轉化為有價值的模型。

知識消化

知識消化并非是一項孤立活動，它一般是在開發人員的上司下，由開發人員與領域專家組成的團隊來共同協作。

領域模型不斷精化迫使開發人員學習重要的業務原理。領域專家被迫提煉自己知道的重要知識的過程往往也是完善自身了解的過程。

分析員和程式員将自己的知識輸入到了模型中，是以模型的組織更嚴密，抽象也更為簡潔，進而為實作提供了更大的支援。同時，由于領域專家也将他們的知識輸入到了模型中，是以，模型反映了業務深層次知識，而且真正的業務原則得以抽象。

模型在不斷地改進的同時，也成為組織項目資訊流的工具。模型聚焦于需求分析。與程式設計和設計緊密互動。通過良性循環加深團隊成員對領域的了解，使他們透徹地了解模型。

模型對了解領域必須是切實可用的。它們必須非常精确，以便應用程式易于實作和了解。

持續學習

當開始編寫軟體時，我們知之甚少。項目零散地分散在很多人和文檔中，其中夾雜着其他一些無關資訊。

高效率的團隊需要有意識地積累知識，并持續學習。對于開發人員來說，這意味着既要完善技術知識，也要培養一些領域模組化技巧。

知識豐富設計

業務活動和隊則如同所涉及的實體一樣，都是領域核心，任何領域都有各種類别的概念。知識消化所産生的模型能夠反映出對知識的深層次了解。在模型發生改變的同時，開發人員對實作進行重構，以便反映出模型的變化，這樣，新知識就被合并到應用程式中了。

深層模型

有用的模型很少應留在表面。随着對領域和應用程式需求的了解和逐漸加深，往往會丢棄那些最初看起來很重要的表面元素，或者切換它們的角度。這時，一些開始時不可能發現的巧妙抽象就會漸漸浮出水面，而它們恰恰切中問題的要害。

知識消化是一種探索，它永無止境。