1、領域模型的重要性

領域模型是軟體專案中的核心,模型是團隊經過長時間的歸納總結形成的一個與專案有關的概念集合,他用術語和關係表達了領域的深層含義,這種關係和語義提供了模型語言的語義,模型語言是為領域獨家定製的.十分的精確,並且他將開發過程和模型繫結到一起,並使程式碼和模型緊密的繫結.

但是還是要說一句,領域模型並非一張圖或者一個表,他是所有能表達模型的手段的集合,可以是一張圖、一段程式碼、一個文字文件、甚至可以是一段錄音,只要內容和領域模型有關,那他就是領域模型的一部分.

2、模式

(1)、傳統開發模式存在的問題

由於語言之間的鴻溝,領域專家和開發人員往往不能得到最初的領域模型,在一個沒有公共語言的專案上,開發人員不得不和領域專家相互協作,努力的構建出第一個模型,但是這個過程很艱難,第一開發人員本身和領域專家之間的鴻溝,如果這個時候存在多個領域專家和多個開發人員,那麼這個過程會更艱難,因為領域專家不得不為開發人員翻譯其它領域專家的知識,這個翻譯過程中間也可能存在問題,這一系列的問題,導致模型越來越模糊.甚至達到了語言支離破碎的地步,那麼這個專案也就失敗了.

(2)、領域模型的作用

所以我們必須對各種領域知識進行抽象,並形成一個領域專家和開發人員達成共識的一種語言。並將其總結成領域模型,持久化起來,形成一種通用的語言,通用語言包含類名稱和主要操作,通用語言還包含一些高階的術語,有些術語知識普通的規則,有些術語則是施加在模型上的高階規則(後續的文章會介紹)。

模型之間的關係成為組合規則,將核心的模型串聯起來.

最後在團隊一直的努力下,開發人員通過基於模型的語言,來編寫程式碼,領域專家使用他來討論開發計劃和需求,隨著時間的推移,語言使用的越普遍,大家的理解就變得越來越深刻.這個過程就像我們學習外語一樣,說的多了,自然就理解了.這個過程也是我們消化領域知識的過程,所以消化知識這個過程是依賴於語言的使用的.

而且隨著我們對通用語言的理解的加深,就能發現其中的問題,這個時候就適當的修改,開發人員也去修改對應的類名稱,或者程式碼,使他進一步的完善.

重點:我們必須認識到對領域通用語言的修改就是對我們的程式碼的修改,所以我們必須重視每次頭腦風暴後的哪些影響現有程式碼設計和有歧義的地方,然後提出來,進行進一步的討論.

3、最小化抽象領域

當每次頭腦風暴過後，團隊必須確定領域中的最小化抽象.這是領域驅動設計的基本要求.

4、解釋性模型

作為一個C#開發,我往往希望使用類圖來變現業務邏輯,像下面這樣

但是類圖無法展示一些操作的細節,這個時候我們就可以引入解釋性模型,來更清楚的展示一些細節的操作,像下面這樣:

通過將類圖和解釋性模型的結合,能同時滿足開發人員和領域專家的需求,兩者同時作為領域模型的一部分,使領域模型更加的容易理解.