使用面向對象抽取領域名詞

作產品會設計到不少的領域，可是這些領域中出現的概念每每是比較穩定的，而他們的變化點在於由不一樣的產品（這裏指在這個領域作產品的人）
會根據他們對這個領域以及互聯網的理解去設計他們本身的產品規劃（流程，規則），做爲需求分析的人員來講大部分狀況是咱們是基於產品的原型，prd進行
需求分析和設計的，這裏面其實咱們應該作的第一個工做就是找出這個領域中不變的領域概念（領域名詞）。
下面咱們就來介紹一下俺們大神使用面向對象的方式抽取領域名詞的步驟。

須要知道

• pojo對象屬於對系統的靜態描述。它確定是名詞。
• 抽取領域名詞的最終目的是爲了數據存儲。
  這些名詞必定會轉換後面咱們系統中存在的實體，表，因此它也是整個應用或者產品的數據來源就肯定。
  好比一個頁面或者功能須要使用什麼數據就能夠快速找到對應的對象或者經過對象的關係找出來。

肯定對象列表

窮舉名詞

若是有原型就在原型中查找全部名詞，從左到右從前到後一個名詞都不放過，
把你全部認爲能夠做爲備選的所有列出來。
若是沒有原型就在客戶或者產品的口中獲取到反覆出現的名詞。

注意：

不要去經過本身的理解去修更名詞叫法
不要去忽略本身以爲不重要的名詞
不要考慮表怎麼存儲
不要考慮非名詞
這些陷阱很容易讓後期返工。

刪除

刪除和產品（領域）無關的名詞。
好比：文案可能出現了故宮或者平臺名等和本領域無關的名詞。

去重

必需確保每一個名詞都是職責單一，不可替代的。
若是兩個名詞在概念上比較類似，可是表面詞語不太同樣的能夠將這兩個詞歸爲一類，刪除多餘的名詞。
通常去重的特徵以下：不一樣的名詞體現出來的屬性，功能和生命週期是同樣的，只是描述不一樣。
好比： 不一樣角色的人在對同一個名詞描述不一樣，他們在新增的時候屬性類似度很是高，流程也特別像。
通常的反問本身或者產品：

• 它們的不一樣點在哪？
• 若是改一個地方，另外一個地方會不會須要同時修改？
• 若是把它們作成同樣會有什麼問題嗎？

聚合

把屬性名詞聚合到其餘跟內聚的對象裏。
有一些名詞都是能夠分到一個組中去的，好比：程序員，人事，cto,都是公司的員工，因此能夠分到員工對象中去。
這裏只放自描述屬性，其餘的屬性暫時不考慮，由於能夠很方便的經過關係來描述，並且這個也常常會變化。

添加

在描述一個概念的時候，必須經過很是多其餘對象，並且常常提。
雖然產品沒有提過，可是在實施的時候發生有不少對象有同樣的特性。常見狀況：

• 一個列表涉及到很是多的名詞，可是列表自己產品並無體現概念。
• 不一樣的名詞，他們的屬性很雷同，並且生命週期幾乎是同樣的，有種幾條平行線的感受。好比說：一樣要新增、發佈、審覈等

肯定這個名詞的職責

在作項目中咱們不免會作超出咱們認知範圍內的領域知識，
找產品和客戶搞清楚這些名詞的含義，能夠幫助咱們肯定這個名詞的描述。
好比：課表：是學生報名以後根據所報年級的課產生的上課安排。

到目前爲止領域中的核心名詞都抽取出來了，也肯定了這個名詞的含義，也就是說咱們的對象列表以及對象的職責也就肯定了。
下面就是該找這個對象的屬性了。

肯定對象的屬性

屬性分類

一個對象的屬性大體分爲幾個類型：
自描述屬性，關聯屬性，冗餘屬性，功能性屬性

自描述屬性

通常體現出來的就是手動輸入。好比：名稱，標題，描述等等

關聯屬性

有依賴來源，即在別的地方是手動輸入，可是當前功能是選擇。好比：選擇地區，選擇類型

冗餘屬性

方便查詢，減小複雜度。通常有如下狀況：

• 一旦生成不會變化的，能夠考慮冗餘，由於這樣能夠減小複雜度。
• 偏統計類。好比：視頻裏冗餘評論數購買數。
• 爲了減小不一樣類型表的依賴。

功能性屬性

個性化業務，純粹是爲了作功能

建議：

只留自描述，這個很難。須要深層次瞭解領域。經過領域驅動設計。這樣能夠經過面向對象，經過不多的關注點，對整個系統有個靜態的認識。並且還能夠判斷出產品變動的時候對整個系統的結構（即數據存儲）有什麼影響。特別是出現新名詞的時候。
須要根據產品的實際狀況來判斷這些屬性怎麼規劃。
若是是想要快速、簡單，可是4種類型都放到pojo上，開發是最快的，
可是同時確定也是擴展性最差的。
也須要根據產品的真實需求來判斷怎麼處理後面3種類型的屬性。

結束語

這些都是和咱們大神交流學習得來的，看起來會有一些晦澀難懂，後面會根據一個實際項目進行舉例。
最後附上大神博客園：
http://www.cnblogs.com/ansn001/