如果你連業務領域建模都不會，那還怎么做架構師呢？

大家好，我是飄渺Jam，是一位來自三流城市三流公司的三流程序員。今天我們來聊聊如何做業務領域建模，希望能對你有所幫助！

領域模型的概念及作用

領域模型是對領域內的概念類或現實世界中對象的可視化表示。又稱概念模型、領域對象模型、分析對象模型。它專注于分析問題領域本身，發掘重要的業務領域概念，并建立業務領域概念之間的關系。概念比較深奧，其實說白了就是我們把基于對業務的理解畫成一個類圖，并畫出這些類之間的關系（面向對象）。

領域模型可以整理業務中的概念以及關系，幫助團隊中的成員對業務的理解保持一致，往后可以指導數據庫設計、系統功能設計、指導開發。在整個系統建設周期能起到 上接需求，下承開發 的作用。

那既然領域模型如此重要，我們是不是要在類圖中盡可能的展示對象的屬性和方法，以便更好的指導后續的開發設計。

恰恰相反，我們在建模的時候不要將注意力集中在屬性或行為上，應該擺脫這些細枝末節，抓住領域對象定義的最基本特征，只需要體現對象模型的重要概念。如果細節過多很容易產生 ”只見樹木，不見森林“ 的現象。

下面我們看一個簡化后的報銷業務的領域模型，加深一下印象。

完成一個領域模型建模，主要需要做兩件事：

定義類的關鍵屬性和關鍵行為；

定義類與類之間的關聯關系。

定義類的屬性和行為

定義類的屬性和行為比較簡單，用設計工具拖一個class即可，這里只需要注意一下屬性和行為的訪問權限。

- 表示private # 表示protected ~ 表示default,也就是包權限 + 表示public

1

2

3

4

定義類與類之間的交互關系

在UML類圖中，定義了六種類之間的關系，他們分別是： 泛化（Generalization）, 實現（Realization），關聯（Association)，聚合（Aggregation），組合(Composition)，依賴(Dependency)。關系比較多，而且有些還比較相近，比如聚合和組合，接下來我們逐漸講解：

介紹：

泛化(Generalization)表示類與類之間的繼承關系，接口與接口之間的繼承關系。

圖例：

使用 空心三角形+實線 表示。

代碼實現：

public class A { } public class B extends A { }

1

2

3

4

5

6

7

介紹：

實現(Realization)表示一個class類實現interface接口（可以是多個）的功能。

圖例：

使用 空心三角形+虛線 表示。

代碼實現：

public interface A { } public class B implements A { }

1

2

3

4

5

6

7

介紹：

聚合（Aggregation）表示一種弱的 ‘擁有’ 關系，即has-a的關系，體現的是A對象可以包含B對象，B類生命周期可以不依賴A類對象的生命周期， 也就是說可以單獨銷毀A類對象而不影響B類對象，比如課程與學生之間的關系。

圖例：

使用 空心的菱形+實線箭頭 表示。

代碼實現：

public class A { private B b; public A(B b){ this.b = b; } }

1

2

3

4

5

6

介紹：

組合（Composition）表示一種強的 ‘擁有’ 關系，即contains-a的關系，體現的是A對象包含B對象，B類生命周期依賴A類對象的生命周期，B類對象不可單獨存在，比如鳥與翅膀之間的關系。

圖例：

使用 實心的菱形+實線箭頭 表示，還可以使用連線兩端的數字表示某一端有幾個實例。

代碼實現：

public class A { private B b; public A () { this.b = new B(); } }

1

2

3

4

5

6

介紹：

關聯（Association)是一種非常弱的關系，包含聚合、組合兩種關系。對于兩個相對獨立的對象，當一個對象負責構造另一個對象的實例，或者依賴另一個對象的服務時，這兩個對象之間主要體現為依賴關系。具體到代碼層面，如果B類是A類的成員變量，那么B類和A類就是關聯關系。

圖例：

使用實線箭頭表示。

代碼實現：

public class A { private B b; public A(B b){ this.b = b; } }

1

2

3

4

5

6

或者

public class A { private B b; public A () { this.b = new B(); } }

1

2

3

4

5

6

介紹：

依賴(Dependency) 是比關聯關系更加弱的關系，包含關聯關系。不管是B類對象是A類對象的成員變量，還是A類方法使用B類對象作為參數或者返回值、局部變量，只要B類對象和A類對象有任何使用關系，我們都稱他們有依賴關系。

圖例：

使用 虛線箭頭 表示。

代碼實現：

public class A { private B b; public A(B b){ this.b = b; } }

1

2

3

4

5

6

或者

public class A { private B b; public A () { this.b = new B(); } }

1

2

3

4

5

6

或者

public class A { public void func(B b) ... } }

1

2

3

4

5

模型簡化

嚴格的UML類圖之間的關系拆分的太細，專業要求很高，大大增加了學習成本，而且對于業務溝通，指導后續數據庫設計，編程開發沒有太大意義。

所以在實際業務建模過程中，我們并不需要嚴格按照UML類圖交互關系來描述業務實體之間的關系，比如我們可以將聚合、組合、關聯統統使用關聯關系表示，使用實線連接兩個實體，并在兩側標記出實例個數即可。

小結

領域模型最終呈現后的結果很簡單，但是過程卻很復雜。需要架構師基于自身的業務知識和類似產品的參考，再結合客戶、業務專家、領域專家的咨詢和指導，需要經過不斷推倒、修改優化才能完成。

對于剛開始接觸領域模型的繪制時經常會出現下面兩種典型錯誤：

將待開發系統也放在領域模型里面

待開發系統要不要出現在領域模型中取決于你的業務離開待開發的系統能不能玩的轉。舉個例子：如果開發的是共享單車的信息系統，共享單車離開信息系統肯定玩不轉，所以這時候信息系統需要出現在領域模型。

概念劃分不清，關系沒有畫到位

比如屬性畫成了類，繼承關系搞錯

UML

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。