讓技術人員看得懂的流程（3）——領域模型

               讓技術人員看得懂的流程（3）

                            ——領域模型

按照一般的項目管理過程，“需求”之後是“分析”，那麼在分析階段對應的技術流程又是哪個？如何将需求階段和分析階段聯系起來呢？答案就是“領域模型”

什麼是“領域模型”呢？隻要抓住“領域（domain）”二字就可以了解，也就是說領域模型是幫助我們了解相關領域知識的模型。

進一步來問：為什麼需要領域模型？前面不是有“用例模型”嗎，看起來用例模型好像就是描述相關領域知識的，是否完成用例模型就可以進行設計了？

如果你曾經寫過用例文檔，或者仔細看過用例文檔，那麼你肯定知道“用例”本身和“面向對象”、“類”這些都沒有關系，用例就是純自然的語言（比如英語、漢語）寫的，因為用例實際上由客戶口述給我們、然後由我們形成文檔化的用例文檔，客戶才不管我們是什麼面向對象還是面向過程還是阿貓阿狗的。

是以，單純從用例來看，是沒有類的概念的，無法完成從自然語言到面向對象語言的轉換。但是，既然我們已經完成了用例模型，那麼就必須基于用例模型進行分析(否則用例模型豈不是白做了)，而“領域模型”就是自然語言向面向對象語言的一座橋梁。

讓我們來看看“領域模型”階段我們要做什麼、該怎麼做。其實很簡單，簡單概括就是“找名詞”，分為四個步驟：（1）找出用例模型中的名詞，（2）然後識别這些名詞本身的相關資訊，（3）以及名詞之間的互相關聯關系，（4）用uml畫出領域模型。

我們來看在“用例模型”章節中的post用例如何得出領域模型。

第一步：找出用例模型中的名詞

原有用例如下，用藍色加黑标出名詞（重複的就不标了）：

1）顧客攜帶商品到收銀台；

2）收銀員掃描商品條形碼；

3）系統根據條形碼擷取并顯示商品資訊；

4）收銀員重複2~3步，直到所有商品掃描完畢；

5）系統計算商品總額；

。。。。。。。。。。。。。。。。。。。。

n）系統打出商品清單，完成交易。

這個用例中的名詞有“顧客”、“商品”、“收銀台”、“收銀員”、“商品條形碼”、“系統”、“商品資訊”、“商品總額”、“商品清單”、“交易”。稍加整理：

1）“顧客”、“收銀員”是系統的外部對象，不需要我們進行設計，但這些對象要和系統進行互動；

2）“商品”、“商品條形碼”、“商品資訊”、“商品總額”、“商品清單”、“交易”是領域對象，但“商品條形碼”、“商品資訊”可以算作“商品”的屬性、“商品總額”可以算作“交易”的屬性，最後從這個用例總結出來的領域對象有“商品”、“商品清單”、“交易”三個。

第二步：識别這些名詞本身的相關資訊

一個對象的屬性可能分布在多個用例中，是以可以通過疊代不斷的完善一個對象的屬性，大家可以看到，我們在第一步中的樣例就已經分析了一部分了：“商品條形碼”、“商品資訊”可以算作“商品”的屬性。

對象除了屬性外，還有一些限制或者限制，這些在用例中可能有，也可能沒有，這就需要分析人員來發現了。比如說交易金額必須大于0.1元小于99999元這種限制，用例中不一定會展現，可能需要分析人員向客戶咨詢。

第三步：識别對象間的關系

面向對象設計就是依靠對象間的互相協作來配合完成相應的功能，是以識别出對象和對象本身的屬性外，還要識别對象間的關系，例如1對多、1對1、依賴等，詳細的各種關系可以參考uml的标準定義。

我們以第一步識别的三個對象為例：“商品清單”包含多個“商品”、一次“交易”對應一個“商品清單”、一個“商品”隻能屬于一個“交易”等。

第四步：畫出領域模型uml圖

uml這裡就不啰嗦了，我們結合前三步的分析，畫出這個樣例的uml領域模型圖：

 （由于csdn關閉了圖檔上傳功能，是以無法貼出，大家可以根據前三步自己畫一個）

大家可以看到，經過“領域模型”的分析後，已經完成了自然語言到面向對象語言的初步轉化了，領域對象已經識别出來，面向對象已經初具雛形。

需要提醒的是：領域模型過程中識别出來的對象和具體的語言無關，也沒有方法。換句話說，public、private、函數這些面向對象的屬性在領域模型階段不需要分析出來。