2013-12-11 43 views
4

我讀到的域模型和它的重要性和我有以下幾點疑惑:UML中的域模型?

  • 可以用一個領域模型解決什麼樣的問題?換句話說,對於每個問題,我應該建立一個領域模型?

  • 據我所知,域模型使用類圖表示。類圖和域模型之間沒有區別?

  • 我也想明白在哪個方面詞彙相關的領域模型?

回答

11

可以用一個領域模型解決什麼樣的問題?

幾乎任何問題,你想/需要提供一個軟件解決方案是適合建模。事實上:無論你做什麼,你都必須以某種方式,形狀或形式「塑造」你的問題領域。如果您不以軟件的方式捕捉問題的規則和政策,那麼終端系統很難達到預期的要求。

換句話說,對於每個問題,我應該建立一個領域模型?

這取決於您所說的「構建域模型」。見上面和下面...

據我所知,域模型使用類圖表示。類圖和域模型之間沒有區別?

類圖是一個模型域的方法。實際上,他們是模型部分域的一種方式。類圖的主要優點是它明確而清晰地揭示了問題空間中的關係。有一種觀點認爲,域的語義主要是通過概念(類)之間的關係產生 - 比類本身更重要。如果你認同這個觀點,那麼你可能/可能會發現一個有用的類圖。

但請注意,類圖僅捕獲域的結構元素:類,屬性和關係。 CD不捕獲行爲。如果要以任何有用的方式對問題空間進行建模,則領域模型需要結構和行爲。所以你需要用一些行爲描述來增加類圖。例如狀態模型和/或動作。

也有其他的方法來模擬域。它可以是一組java/c#類。這種方法的主要缺點是對關係的重視程度下降。與類圖不同,OO語言不提供關係作爲第一類結構。其優勢在於,與大多數建模工具相比,編程語言環境(編輯器/編譯器/庫/語言運行時)爲定義域的行爲方面提供了更好的支持。

更一般地說,沒有規則說域模型必須遵循面向對象的範例。它可以是Haskell或OCAML中的一組函數和類型。或者它可能是一些微分方程或其他數學結構。

關鍵是模型 - 不過表達 - 提供了問題空間的描述。爲了有用,描述不會是完整 - 它只會捕獲與系統需求相關的問題空間中的屬性子集。然而,它應該是正確 - 捕獲的概念和行爲應該準確地反映正在建模的世界。

我也想明白在哪種方式是與領域模型相關的詞彙?

您可以將領域模型視爲一種產生形式化且高度結構化的詞彙表的方法。實際上,它也捕捉了一些語法;例如它說,「所有權」關係的參與者必須是一個狗和一個人;不是兩隻狗,或一個人和一把勺子。

這就是埃裏克埃文斯在Domain Driven Design中所說的無處不在的語言。這意味着模型中使用的術語應該準確地反映正在建模的問題的術語。所以如果真實世界的領域專家使用「人」和「狗」這個詞,模型就不應該使用「智人」和「犬」。理由很簡單:如果開發人員(建模者)使用與領域專家相同的術語,那麼誤解的可能性就會降低。由於每個人都在使用熟悉的詞彙,並且具有共同的含義,它還可以帶來更有成效和愉快的對話。

摘要

  • 域模型是一種抽象。它代表了系統解決的現實世界問題固有的概念,規則和政策的一個子集。
  • 類圖是表示域模型結構方面的一種方法。它不捕獲動態方面。這些同樣重要。
  • 還有其他方法可以模擬一個域。它們不限於面向對象的範例。
  • 域模型應該是問題空間的結構化詞彙表。它應該採用該領域專家使用的術語。

hth。

+0

真的很有用的信息@sfinnie謝謝你。 '好處是編程語言環境比定義大多數建模工具提供了更好的支持來定義域的行爲方面,請您能澄清一下上面的引用? 以前,我認爲領域模型只與統一過程(UP) 有關,但現在,無論何時何地我都可以使用它。 – Andrew

+1

歷史上,UML在爲行動提供支持方面一直很薄弱; if/then,while循環,計算等。這意味着很難在UML中定義行爲邏輯。標準現在包含了這個(動作語義&alf)的各種選項,但它仍然是工具的早期階段。相反,編程語言已經提供了很好的支持。是的 - 沒有關於域模型的特定RUP。例如,它是Domain-Driven Design的核心。心連心。 – sfinnie