前面 我們講了如何從業務領域獲取知識，創建領域模型，那么建立領域模型應當注意什么呢？

建立領域模型應當注意的問題

1 ．領域模型不是數據模型，也不是軟件對象模型

一個創建領域模型的過程中非常容易犯的錯誤就是，將領域模型當成了數據模型，或者軟件對象模型。領域模型，又稱為概念模型、領域對象模型或分析對象模型，是“專用于解釋業務領域中重要的‘事物’和產品” [RUP] 。領域模型專注于現實世界的對象（概念類）而非軟件世界的對象。它不包含任何數據庫元素、軟件類、系統架構以及有職責的軟件對象。日后的分析模型、設計模型以及數據模型，將以領域模型作為參考，但很可能與領域模型存在較大差異。因此在建立領域模型的時候，不要與這些模型混淆了。

過去 C/S 的年代，需求分析往往畫的是數據模型。數據模型，也就是我們常說的 E-R 模型（實體 - 關系模型），它是基于關系數據庫的一種分析模型，其間包含了大量的數據庫元素，如主鍵、外鍵、數據依賴等等。領域模型不是數據模型，它不應當包含這些內容。

領域模型與軟件對象模型同為類圖，從而造成領域模型常常與這類模型產生混淆。領域模型是對現實世界的對象的反映，因此領域模型不應包含諸如工廠類、窗口界面、軟件架構之類的軟件元素，領域模型也不等同于之后用于設計開發的分析模型和設計模型。

領域模型中的概念類通常都只有相關的主要屬性，沒有任何的方法或函數（有時候概念類連屬性都可以省略，僅僅描述它們之間的關系）。

2 ．領域模型不是一張圖，而是一系列圖形

我在前面曾經提到過，一張復雜而凌亂的類圖常常使人迷惑，領域模型也是一樣的。領域模型應當劃分成一個又一個的場景，每個場景一張圖，進行領域分析。根據實際需要，這個場景可以大也可以小。如果某個模塊涉及的概念不多并且關系清晰，我們可以使用一個較大的場景進行描述；如果某個模塊涉及的概念紛繁并且關系復雜，我們可以劃分成一些更小的場景分別進行描述。領域模型劃分的場景不論粗還是細，宗旨便是讓讀者閱讀時清晰明了。

3 ．草圖還是建模工具，是個問題

建立領域模型，使用草圖還是建模工具呢，這是個問題。按照過去 RUP 的思想，建模都應當使用 Rational Rose 這樣的建模工具，一步一步地建立一個又一個的模型，然而敏捷開發徹底打破了這一思想。 Robert Martin 在他的著作《敏捷軟件開發》中強烈建議使用草圖進行建模，然后通過掃描草圖形成最終的文檔。我對此也進行了許多的嘗試，我的建議是，建模的初期最好不要使用建模工具。建模的初期，不可避免的是模型的反復修改。如果使用建模工具則意味著每一次的修改都必須進行大量的維護工作，沒有草圖來得方便快捷。當模型逐漸趨于定型以后，可以嘗試使用建模工具進行建模，使模型的建立顯得更加正規，也便于日后的閱讀和使用。

?

?

對領域模型的深入思考

在建立領域模型中，我們通過與客戶的溝通，提取出業務領域的概念類，并歸納出這些概念類之間的相互關系。我們做這些事情為我們的需求分析帶來什么益處呢？

1 ．語言的溝通

在軟件項目的需求調研過程中，語言溝通一直是困擾我們的一大難題。業務人員在他們自己的領域中有一套他們自身的語言，運用這套語言，他們相互之間可以靈活自如地溝通；軟件技術人員在我們的技術領域有我們的一套語言，運用這套語言，我們也可以輕松愉快地溝通。但是，當業務人員和技術人員坐在一起時，問題就出現了。業務人員和技術人員他們各自說各自的一套語言，各說各的話，相互溝通就存在了巨大地障礙。按照以往的經驗，解決這個問題的辦法就是，技術人員通過自身的努力去掌握業務語言，用業務語言去溝通；業務人員耐心地去解釋業務術語給技術人員聽，一步一步地去講解業務領域的一個個流程。這樣的過程是一個艱巨的過程。怎樣讓這樣的過程更加高效呢？也許畫幾個圖，用圖形化的展示能更加生動形象，從而提高溝通的效率。

同時，領域模型又是日后的技術人員進行分析設計的基礎，因此領域模型所采用的語言必須讓技術人員能看得懂。正因為領域模型所起到的重要作用——業務領域與技術實現的溝通介質，領域模型必須采用一種通用語言。同時，領域模型對一些關鍵的業務術語的解釋，以及各個概念類相互關系的描述，也大大降低了溝通的難度。

2 ．知識的消化

我的一位同事正在設計開發一套財務軟件，他告訴我他正在努力學習財務知識，期望把自己打造成一個財務專家，我笑了。如果我們要開發財務軟件就要成為財務專家，要開發稅務軟件就要成為稅務專家，要開發企業管理軟件就要成為企業管理專家，我們的時間精力不允許我們做的。我們開發一套軟件并不一定要成為這個領域的專家，而是通過與專家的溝通，獲取與我們要開發的軟件相關的，這個領域的知識，這些知識對我們是有用知識。要獲取這些有用知識，并不一定成為這個領域的專家才能獲取。相反，為了成為這個領域的專家，我們可能不得不獲取一些對我們開發軟件無用的知識。掌握這些無用的知識，對我們毫無意義而空耗了我們的寶貴時間。現在的問題是，如何準確地獲取對我們有用的知識呢？

編寫用例模型和領域模型，使我們的精力集中到了我們要開發的軟件上來。通過它們，我們把我們的注意力集中到了我們要開發的軟件，以及與軟件相關的所有流程和概念上了。有了這樣一個明確的目標，才能讓我們掌握業務領域的知識更加高效快捷。

另一個我們不能忽視的問題就是知識的延續性。當需求分析人員理解并掌握的業務領域的知識以后，其實工作并沒有完成，他必須把這些知識傳遞給那些相關的技術人員。只有技術人員掌握了這些知識以后，才能開發出合格的軟件產品。當軟件開發結束以后，這個知識還在延續，還要傳達給今后的維護人員，甚至再往后的二次開發人員。領域模型的不斷積累，就是這種領域知識的不斷延續。

3 ．低表示差異

OOA/D 的核心思想就是，軟件系統中的所有對象都是有各種職能的、高度內聚的對象，軟件功能的實現就是這些對象根據各自的職能相互配合完成的。為了實現這樣一個設計思想，低表示差異的概念被提出來了。什么是低表示差異呢？說得更加直白一點兒就是，軟件中的對象及其職能，與現實世界中對應的事物及其職能，應保持盡量接近。低表示差異為降低軟件設計難度，提高系統可讀性，都帶來了極大好處。毫無疑問，在需求分析階段建立領域模型，大大提高了軟件設計的低表示差異。

?

?

參考文獻：

?

?

中文名：《領域驅動設計——軟件核心復雜性的應對之道》

英文名： Domain-Driven Design: Tackling Complexity in the Heart of Software

作者： Eric Evans

?

?

?

中文名：《敏捷軟件開發：原則，模式和實踐》

英文名： Agile Software Development: Principles, Patterns, and Practices

作者： Robert Martin

?

?

相關文章：

《 談談領域模型的那些事兒 之 從業務領域獲取知識 》

談談領域模型的那些事兒 之 注意什么