1. 程式人生 > >領域模型,你真的理解的了嗎?

領域模型,你真的理解的了嗎?

isp des iaas 用戶 tle 思考 管理系 關於 文章

領域模型,你真的理解的了嗎?

背景

UML比較難學,主要是其本身很復雜並且涉及到大量的概念名詞。領域模型就是其中之一,網絡上搜索到關於領域模型的知識應該是有兩種,一種是來源於最初的傳統軟件開發過程,一種來源於領域驅動設計(DDD),這兩者很容易混淆。以下是我對領域模型這個概念的一些理解。

1. 領域模型是什麽?

理論派觀點:

  • Domain Model是一個商業建模範疇概念,即使一個企業不開發軟件,也具備其業務模型;
  • 所有同行企業,其業務模型必定有非常大的共性和內在的規律性。
  • 由行業內的各個企業的業務模型再向上抽象出整個行業的業務模型,這個模型稱之為“領域模型”。

實戰派觀點:

  • 領域模型是一個分析模型,幫助系統分析人員、用戶認識現實業務的工具,描述的是業務中涉及到的實體及其相互之間的關系,它是需求分析的產物,與問題域相關。
  • 是需求分析人員與用戶交流的有力工具,是彼此交流的語言。

理論派

領域模型是一種特殊的業務模型,它分析範圍是整個行業,抽象出行業裏共性和內在規律性的業務,比業務模型更加抽象,它不屬於軟件開發範疇的概念,與軟件開發無關。

實戰派

領域模型是一種分析模型,在軟件開發過程分析階段用於分析如何滿足系統功能性需求,屬於軟件開發範疇,在UML中主要使用類圖來描述領域模型。

業務模型是業務建模的輸出物,業務建模研究的對象是公司或者組織,業務建模屬於軟件開發過程中的初始階段。

軟件開發過程:業務建模、需求、分析、設計。

在軟件開發過程中我們接觸到的領域模型屬於實戰派。

2. 領域模型作用

理論派

領域模型是一種特殊業務模型,作用都是:

  • 幫助分析理解復雜業務領域問題。
  • 行業內溝通、交流。

實戰派
領域模型作用:

  • 分析如何滿足系統功能性需求。
  • 指導項目後續的系統設計。

業務模型作用:

  • 幫助系統需求人員理解客戶公司業務,下一階段做需求以業務模型為輸入得到系統用例。

3. 領域模型與業務模型的區別

理論派

領域模型是一種特殊的業務模型,所以具備業務模型的所有特點,但是比業務模型更抽象、更通用。

實戰派

  • 產出階段不同

業務模型是在軟件開發過程中業務建模階段產生,領域模型是在分析階段產生。

  • 作用不同

業務模型是系統需求人員理解客戶公司業務的產物,下一階段需求將以業務模型為輸入得到系統需求。

領域模型是系統分析人員分析如何滿足系統功能性需求的產物。下一階段設計將以領域模型為輸入。

“實戰派”舉例說明:

當接到項目,需要做一個酒店預訂系統,首先進行業務建模,了解客戶公司酒店管理的相關業務,這就會產出業務模型,此時業務模型裏除了酒店預訂這個業務環節還包括其他與酒店預訂同層次的業務環節。

接下來將視線聚焦到酒店預訂,改進已有流程得到酒店預訂系統需求,即系統用例和需求規約。

接下來通過分析系統用例和需求規約,分析如何滿足酒店管理系統功能性需求,從而得到領域模型。

"理論派"和“實戰派”的領域模型是兩個範疇的東西,若沒有分清肯定會引起理解混亂。

4. 另一種“領域模型” - 領域驅動設計(Domain-Driven Design)

還有一種“領域模型”,它出自於Eric Evans的“Domain-Driven Design”簡稱DDD,也就是“領域驅動設計”,DDD是一套綜合軟件系統分析和設計的面向對象建模方法,所以要明確區分這兩種領域模型。失血模型、貧血模型、充血模型這類概念都屬於DDD範疇的“領域模型”。

4.1 兩種領域模型的區別

本文中“領域模型”都代表領域驅動設計中的領域模型。

1. 解決的核心問題不同

正如前文所說的,領域模型是一個用於分析業務的分析模型,在實際項目中要解決的核心問題是:

  • 如何滿足待開發系統業務功能需求。

而“領域模型”是綜合分析與設計的模型,要解決的核心問題是:

  • 保證系統設計能滿足項目多變的需求。

在傳統的軟件開發流程中,分析(系統需求分析)和設計(系統設計)被劃分為兩個階段,分別對應國家“系統分析師” 和“系統設計師” 兩種職稱,這種割裂的結果導致,“系統設計師”要基於需求分析的結果做系統設計後才能進行編碼,這中間會存在信息上的丟失或失真,並且實際過程中業務需求會變(可能是外界環境的變化或者對業務有更深的理解引起),就更容易引起系統設計與項目需求脫節。Eric Evans提出的DDD思想就是想解決這樣問題。

2. 領域不同

領域模型是業務分析模型,分析的是系統功能性需求所出核心域的業務,軟件系統只是實現業務的方式而非業務的一部分(提供IaaS服務的公司除外),不會考慮系統設計IT領域裏問題。

“領域模型”是綜合分析和設計的模型,涉及到系統設計,需要思考系統的邊界,故該模型所分析設計的領域是綜合了業務領域和IT領域。

以酒店預訂系統為列,其業務描述如下

  • 所有用戶都可通過酒店訂房管理系統查看酒店客房信息
  • 用戶如需預定需先註冊成會員

以上涉及到兩個對象:用戶、會員。

若做業務分析,第一段描述中的“用戶”可能就需要考慮,它可能是遊客、咨詢者的業務含義。

若要考慮系統設計,第一段描述中的“用戶”可能就會忽略,即不在系統邊界範圍內。

3. 使用的階段和崗位不同

領域模型是分析業務的分析模型,在實際項目中主要由系統分析師在分析階段中使用。

DDD的“領域模型”是綜合分析、設計的模型,在實際項目中橫跨分析和設計兩個階段,崗位需要具備“系統分析師”和“系統設計師”的綜合能力。

4. 包含的內容不同

領域模型主要內容:

  • 業務實體
  • 業務實體之間關系

“領域模型”主要內容:

  • 業務實體
  • 業務實體屬性
  • 業務實體之間關系
  • 服務
  • 服務與實體之間的關系

5. 總結

領域模型分理論派和實戰派,理論派屬於商業範疇不屬於軟件開發範疇,軟件開發過程不用理會理論派,切忌相互混淆。

實戰派認為領域模型是一種分析模型,用於分析理解復雜業務領域問題,具體到軟件開發過程中就是在分析階段分析如何滿足系統功能性需求。

同時在軟件開發範疇還有來自於DDD的“領域模型”,這是一種綜合分析與設計一體的模型,註重系統設計與需求分析、系統需求的銜接,設計出系統與需求有較好的一致性,針對合理的需求變化也更具有良好的擴展性。

6. 參考文章

  • 軟件方法 - 建模和UML
  • 領域驅動設計(DDD:Domain-Driven Design)
  • 面向對象與領域建模
  • 來源網址 https://www.jianshu.com/p/fe45506ea358

領域模型,你真的理解的了嗎?