領域模型的概念及做用
領域模型是對領域內的概念類或現實世界中對象的可視化表示。又稱概念模型、領域對象模型、分析對象模型。它專一於分析問題領域自己，發掘重要的業務領域概念，並創建業務領域概念之間的關係。概念比較深奧，其實說白了就是咱們把基於對業務的理解畫成一個類圖，並畫出這些類之間的關係（面向對象）。java
領域模型能夠整理業務中的概念以及關係，幫助團隊中的成員對業務的理解保持一致，日後能夠指導數據庫設計、系統功能設計、指導開發。在整個系統建設週期能起到 上接需求，下承開發 的做用。數據庫
那既然領域模型如此重要，咱們是否是要在類圖中儘量的展現對象的屬性和方法，以便更好的指導後續的開發設計。編程
偏偏相反，咱們在建模的時候不要將注意力集中在屬性或行爲上，應該擺脫這些細枝末節，抓住領域對象定義的最基本特徵，只須要體現對象模型的重要概念。若是細節過多很容易產生 」只見樹木，不見森林「 的現象。微信
下面咱們看一個簡化後的報銷業務的領域模型，加深一下印象。架構
完成一個領域模型建模，主要須要作兩件事：數據庫設計
-
定義類的關鍵屬性和關鍵行爲；工具
-
定義類與類之間的關聯關係。學習
定義類的屬性和行爲
定義類的屬性和行爲比較簡單，用設計工具拖一個class便可，這裏只須要注意一下屬性和行爲的訪問權限。優化
- 表示private # 表示protected ~ 表示default,也就是包權限 + 表示public
定義類與類之間的交互關係
在UML類圖中，定義了六種類之間的關係，他們分別是：泛化（Generalization）, 實現（Realization），關聯（Association)，聚合（Aggregation），組合(Composition)，依賴(Dependency)。關係比較多，並且有些還比較相近，好比聚合和組合，接下來咱們逐漸講解：this
泛化（Generalization）
介紹：
泛化(Generalization)表示類與類之間的繼承關係，接口與接口之間的繼承關係。
圖例：
使用 空心三角形+實線 表示。
代碼實現：
public class A { } public class B extends A { }
實現（Realization）
介紹：
實現(Realization)表示一個class類實現interface接口（能夠是多個）的功能。
圖例：
使用 空心三角形+虛線 表示。
代碼實現：
public interface A { } public class B implements A { }
聚合（Aggregation）
介紹：
聚合（Aggregation）表示一種弱的 ‘擁有’ 關係，即has-a的關係，體現的是A對象能夠包含B對象，B類生命週期能夠不依賴A類對象的生命週期， 也就是說能夠單獨銷燬A類對象而不影響B類對象，好比課程與學生之間的關係。
圖例：
使用 空心的菱形+實線箭頭 表示。
代碼實現：
public class A { private B b; public A(B b){ this.b = b; } }
組合(Composition)
介紹：
組合（Composition）表示一種強的 ‘擁有’ 關係，即contains-a的關係，體現的是A對象包含B對象，B類生命週期依賴A類對象的生命週期，B類對象不可單獨存在，好比鳥與翅膀之間的關係。
圖例：
使用 實心的菱形+實線箭頭 表示，還可使用連線兩端的數字表示某一端有幾個實例。
代碼實現：
public class A { private B b; public A () { this.b = new B(); } }
關聯（Association)
介紹：
關聯（Association)是一種很是弱的關係，包含聚合、組合兩種關係。對於兩個相對獨立的對象，當一個對象負責構造另外一個對象的實例，或者依賴另外一個對象的服務時，這兩個對象之間主要體現爲依賴關係。具體到代碼層面，若是B類是A類的成員變量，那麼B類和A類就是關聯關係。
圖例：
使用實線箭頭表示。
代碼實現：
public class A { private B b; public A(B b){ this.b = b; } }
或者
public class A { private B b; public A () { this.b = new B(); } }
依賴(Dependency)
介紹：
依賴(Dependency) 是比關聯關係更加弱的關係，包含關聯關係。不論是B類對象是A類對象的成員變量，仍是A類方法使用B類對象做爲參數或者返回值、局部變量，只要B類對象和A類對象有任何使用關係，咱們都稱他們有依賴關係。
圖例：
使用 虛線箭頭 表示。
代碼實現：
public class A { private B b; public A(B b){ this.b = b; } }
或者
public class A { private B b; public A () { this.b = new B(); } }
或者
public class A { public void func(B b) ... } }
模型簡化
嚴格的UML類圖之間的關係拆分的太細，專業要求很高，大大增長了學習成本，並且對於業務溝通，指導後續數據庫設計，編程開發沒有太大意義。
因此在實際業務建模過程當中，咱們並不須要嚴格按照UML類圖交互關係來描述業務實體之間的關係，好比咱們能夠將聚合、組合、關聯通通使用關聯關係表示，使用實線鏈接兩個實體，並在兩側標記出實例個數便可。
小結
領域模型最終呈現後的結果很簡單，可是過程卻很複雜。須要架構師基於自身的業務知識和相似產品的參考，再結合客戶、業務專家、領域專家的諮詢和指導，須要通過不斷推倒、修改優化才能完成。
對於剛開始接觸領域模型的繪製時常常會出現下面兩種典型錯誤：
-
將待開發系統也放在領域模型裏面 待開發系統要不要出如今領域模型中取決於你的業務離開待開發的系統能不能玩的轉。舉個例子：若是開發的是共享單車的信息系統，共享單車離開信息系統確定玩不轉，因此這時候信息系統須要出如今領域模型。
-
概念劃分不清，關係沒有畫到位 好比屬性畫成了類，繼承關係搞錯
以上，但願對你有所幫助！
本文分享自微信公衆號 - JAVA日知錄（javadaily）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。