在項目中使用領域驅動建模

一、關於領域建模的說明

領域建模不是一個新概念了，領域建模專家Eric Evans在04年發表了《Domain Driven Design》一書後，業界已經開始使用。06年清華大學出版了中文版本後，領域驅動設計在一些web項目中被廣泛的使用了。值得說明的是，領域模型不僅僅局限在web項目中可被使用，在資料庫專案、網路部署、分析計算中的項目中也非常適用。領域模型是一種思維﹐是一種方法，是在系統分析階段把握問題本質的有效途徑。

下面我們關注下什麼是領域建模。

二、什麼是領域建模

什麼是領域模型，合適的概念都比較抽象。不如從實戰這樣理解：基於分析階段和設計階段，用領域驅動設計的方法整理出來的一些分析模型。領域驅動設計的方法其實就是面向現實世界，立足現行系統，對領域內的概念類進行抽象和表示。所以整理出來的領域模型，也被稱為概念性模型、領域物件模型等。如下：

 

從業務理解的角度看的話，分析人員們和專家們勾勒出來的領域知識的骨架視圖，這就是領域模型了。不要期望專家們會交給你一個關於他們問題域的完整描述，只能靠自己基於OO思想，規划出業務方的基本業務內容，如所示。

由此，我們想到，概念性模型不就是畫出項目的類圖嗎，沒有這麼簡單！領域模型是體現業務內容和軟體系統兩個專業領域的交匯，需要對概念進行彙總和模式組合，比較理想的是可以做到MDD（模型驅動設計）和MDA（模型驅動架構）。同理，基於軟體系統整理的模型也需要和現實世界進行充分的映射。

三、領域建模的作用

領域模型的作用。其實，通過前面第二部分的描述，已凸現了其作用了。這裡概況一下：

1、領域模型是業務方提供給系統建設最有價值的內容，是系統建設內容的核心所在。在很多文章中，領域模型被稱為是藝術化的技術，是專門用來快速的解決複雜軟體問題的。

2、領域建模，是有效解決分析癱瘓，避免過度設計的一種控制辦法。

3、面對一個複雜的大項目時候，可以統一團隊思想，統一業務口徑，讓模型植根於領域，可以做到分析和設計緊密關聯，設計中的核心部分映射到業務上。

似乎有點過度誇張其作用，總體來看能起到面向待處理的問題，聚焦！

四、如何進行領域建模

如果是面向一個項目的話。介紹一下，從業務到系統，再從系統到業務的過程。如下

1、在業務領域中尋找實體類。業務領域對於沉溺於技術的技術人員來說是陌生的，需要和業務專家進行充分的溝通。要找的這些概念類有一些特性，比如它在整個生命週期內儘管狀態變化特徵完整，有存在和消亡過程。比如，網站的各種產品要做VAS售賣（可能不存在，我們先臆想一個需求），我們尋找的是一些實體，所以你應該不會找旺鋪、商機參謀、E客服等這些具體的產品，因為它太宏大了，這種抽象不能體現概念的生命週期中業務往來。

2、使用UML繪製實體的類圖。UML的使用，對於技術人員來說和寫JAVA或C差不多，因為你是在畫類圖。這個步驟需要做的，是把擷取到的實體類整理成Class Diagram。類之間的關係需要根據擷取的業務知識和OO知識來表達出來。只是，類之間的關係這趟水比較深，我想作為技術人員推敲這個還是很有樂趣的。如果是分析人員在做的話，就需要盡量的和開發人員交流以擷取一個系統視覺。如下，基於上面那個業務先分析如下：

3、添加關聯和屬性。添加屬性和關聯相當於在骨骼上添加血肉。對接下來進入設計階段提供比較理想的需求說明。當然，分析人員可提供擷取到的附加領域知識給開發人員，讓其補充完整也是可行的。因為是OO的知識內容，不用多說。有可能的如下結果：

設計需要根據分析模型在從系統實現上，對其中知識點關聯不正確的內容進行修正，做到映射到系統實現。如果是先由系統出發勾勒模型圖的話，那就需要和業務方來進行需求內容的映射。

對於概念類的抽象需要用到彙總工廠和組合模式，以此來最佳化業務實體

 

 

五、綜合說明

其實我想陳述的觀點是，領域模型是由分析人員和設計共同整理出來的，包括業務專家和系統專家的全面內容，該模型可以起到驅動項目建設的作用，在整個項目過程中作為核心指導存在。

如果你的項目業務領域非常廣，技術角度也很深，可以體驗下領域驅動的辦法，非常有效。