做產品會設計到很多的領域，但是這些領域中出現的概念往往是比較穩定的，而他們的變化點在於由不同的產品（這裏指在這個領域做產品的人）
會根據他們對這個領域以及互聯網的理解去設計他們自己的產品規劃（流程，規則），作爲需求分析的人員來說大部分情況是我們是基於產品的原型，prd進行
需求分析和設計的，這裏面其實我們應該做的第一個工作就是找出這個領域中不變的領域概念（領域名詞）。
下面我們就來介紹一下俺們大神使用面向對象的方式抽取領域名詞的步驟。
需要知道
- pojo對象屬於對系統的靜態描述。它肯定是名詞。
- 抽取領域名詞的最終目的是爲了數據存儲。
這些名詞一定會轉換後面我們系統中存在的實體，表，所以它也是整個應用或者產品的數據來源就確定。
比如一個頁面或者功能需要使用什麼數據就可以快速找到對應的對象或者通過對象的關係找出來。
確定對象列表
窮舉名詞
如果有原型就在原型中查找所有名詞，從左到右從前到後一個名詞都不放過，
把你所有認爲可以作爲備選的全部列出來。
如果沒有原型就在客戶或者產品的口中獲取到反覆出現的名詞。
注意：
不要去通過自己的理解去修改名詞叫法
不要去忽略自己覺得不重要的名詞
不要考慮表怎麼存儲
不要考慮非名詞
這些陷阱很容易讓後期返工。
刪除
刪除和產品（領域）無關的名詞。
比如：文案可能出現了故宮或者平臺名等和本領域無關的名詞。
去重
必需確保每個名詞都是職責單一，不可替代的。
如果兩個名詞在概念上比較相似，但是表面詞語不太一樣的可以將這兩個詞歸爲一類，刪除多餘的名詞。
一般去重的特徵如下：不同的名詞體現出來的屬性，功能和生命週期是一樣的，只是描述不同。
比如： 不同角色的人在對同一個名詞描述不同，他們在新增的時候屬性相似度非常高，流程也特別像。
一般的反問自己或者產品：
- 它們的不同點在哪？
- 如果改一個地方，另一個地方會不會需要同時修改？
- 如果把它們做成一樣會有什麼問題嗎？
聚合
把屬性名詞聚合到其他跟內聚的對象裏。
有一些名詞都是可以分到一個組中去的，比如：程序員，人事，cto,都是公司的員工，所以可以分到員工對象中去。
這裏只放自描述屬性，其他的屬性暫時不考慮，因爲可以很方便的通過關係來描述，而且這個也經常會變化。
添加
在描述一個概念的時候，必須通過非常多其他對象，而且經常提。
雖然產品沒有提過，但是在實施的時候發生有很多對象有一樣的特性。常見情況：
- 一個列表涉及到非常多的名詞，但是列表本身產品並沒有體現概念。
- 不同的名詞，他們的屬性很雷同，而且生命週期幾乎是一樣的，有種幾條平行線的感覺。比如說：同樣要新增、發佈、審覈等
確定這個名詞的職責
在做項目中我們難免會做超出我們認知範圍內的領域知識，
找產品和客戶搞清楚這些名詞的含義，可以幫助我們確定這個名詞的描述。
比如：課表：是學生報名之後根據所報年級的課產生的上課安排。
到目前爲止領域中的核心名詞都抽取出來了，也確定了這個名詞的含義，也就是說我們的對象列表以及對象的職責也就確定了。
下面就是該找這個對象的屬性了。
確定對象的屬性
屬性分類
一個對象的屬性大致分爲幾個類型：
自描述屬性，關聯屬性，冗餘屬性，功能性屬性
自描述屬性
一般體現出來的就是手動輸入。比如：名稱，標題，描述等等
關聯屬性
有依賴來源，即在別的地方是手動輸入，但是當前功能是選擇。比如：選擇地區，選擇類型
冗餘屬性
方便查詢，減少複雜度。一般有以下情況：
- 一旦生成不會變化的，可以考慮冗餘，因爲這樣可以減少複雜度。
- 偏統計類。比如：視頻裏冗餘評論數購買數。
- 爲了減少不同類型表的依賴。
功能性屬性
個性化業務，純粹是爲了做功能
建議：
只留自描述，這個很難。需要深層次瞭解領域。通過領域驅動設計。這樣可以通過面向對象，通過很少的關注點，對整個系統有個靜態的認識。而且還可以判斷出產品變更的時候對整個系統的結構（即數據存儲）有什麼影響。特別是出現新名詞的時候。
需要根據產品的實際情況來判斷這些屬性怎麼規劃。
如果是想要快速、簡單，但是4種類型都放到pojo上，開發是最快的，
但是同時肯定也是擴展性最差的。
也需要根據產品的真實需求來判斷怎麼處理後面3種類型的屬性。