1、領域模型的重要性
領域模型是軟體專案中的核心,模型是團隊經過長時間的歸納總結形成的乙個與專案有關的概念集合,他用術語和關係表達了領域的深層含義,這種關係和語義提供了模型語言的語義,模型語言是為領域獨家定製的.十分的精確,並且他將開發過程和模型繫結到一起,並使**和模型緊密的繫結.
但是還是要說一句,領域模型並非一張圖或者乙個表,他是所有能表達模型的手段的集合,可以是一張圖、一段**、乙個文字文件、甚至可以是一段錄音,只要內容和領域模型有關,那他就是領域模型的一部分.
2、模式
(1)、傳統開發模式存在的問題
由於語言之間的鴻溝,領域專家和開發人員往往不能得到最初的領域模型,在乙個沒有公共語言的專案上,開發人員不得不和領域專家相互協作,努力的構建出第乙個模型,但是這個過程很艱難,第一開發人員本身和領域專家之間的鴻溝,如果這個時候存在多個領域專家和多個開發人員,那麼這個過程會更艱難,因為領域專家不得不為開發人員翻譯其它領域專家的知識,這個翻譯過程中間也可能存在問題,這一系列的問題,導致模型越來越模糊.甚至達到了語言支離破碎的地步,那麼這個專案也就失敗了.
(2)、領域模型的作用
所以我們必須對各種領域知識進行抽象,並形成乙個領域專家和開發人員達成共識的一種語言。並將其總結成領域模型,持久化起來,形成一種通用的語言,通用語言包含類名稱和主要操作,通用語言還包含一些高階的術語,有些術語知識普通的規則,有些術語則是施加在模型上的高階規則(後續的文章會介紹)。
模型之間的關係成為組合規則,將核心的模型串聯起來.
最後在團隊一直的努力下,開發人員通過基於模型的語言,來編寫**,領域專家使用他來討論開發計畫和需求,隨著時間的推移,語言使用的越普遍,大家的理解就變得越來越深刻.這個過程就像我們學習外語一樣,說的多了,自然就理解了.這個過程也是我們消化領域知識的過程,所以消化知識這個過程是依賴於語言的使用的.
而且隨著我們對通用語言的理解的加深,就能發現其中的問題,這個時候就適當的修改,開發人員也去修改對應的類名稱,或者**,使他進一步的完善.
重點:我們必須認識到對領域通用語言的修改就是對我們的**的修改,所以我們必須重視每次頭腦風暴後的哪些影響現有**設計和有歧義的地方,然後提出來,進行進一步的討論.
3、最小化抽象領域
當每次頭腦風暴過後，團隊必須確定領域中的最小化抽象.這是領域驅動設計的基本要求.
4、解釋性模型
作為乙個c#開發,我往往希望使用類圖來變現業務邏輯,像下面這樣
但是類圖無法展示一些操作的細節,這個時候我們就可以引入解釋性模型,來更清楚的展示一些細節的操作,像下面這樣:
通過將類圖和解釋性模型的結合,能同時滿足開發人員和領域專家的需求,兩者同時作為領域模型的一部分,使領域模型更加的容易理解.
領域驅動設計系列 三 事件驅動上
今天講一下事件驅動，這個不是領域驅動設計裡的事件源 event source 這個以後再講，今天主要講一下如何用事件來解耦，主要的原因是我們有個專案有個功能我覺得用事件的方式比較好，正好寫篇部落格，就不用專門給他們講了。說到解耦，我們很熟悉分層設計，比如上層依賴於抽象，不依賴於具體的實現。比如乙個類...
領域驅動設計系列 二 領域模型
領域驅動設計裡有很多東西，我們可以應用在各種各樣的開發模式裡，所以接下來說的一些東西，我們可以部分使用。說道領域驅動的領域，大家肯定就要開始說bounded context,聚合，聚合根，容易讓大家搞糊塗。我覺得先拋開這些概念，後面再來說如何設計聚合，先簡單來說。過去，我們在多層設計裡定義了很多mo...
領域驅動設計系列（一） 為何要領域驅動設計？
領域驅動設計最近貌似開始火起來了，越來越多的人開始認識到領域設計的重要性，從我做過的專案來看，似乎歐洲已經有很多的公司開始實施領域驅動設計了，我看領域驅動設計也有些時間了，但是網上不管是文章還是 都顯得太過 高大上 一談領域驅動設計，一大堆的概念一股腦的給你上上來，搞的有點暈頭轉向，而我想在一些中小...