產品或者服務由數據存儲和數據計算組成。pojo對象就是用於數據存儲。一旦確定後，整個應用或者產品的數據來源就確定。比如一個頁面或者功能需要使用什麼數據就可以快速找到對應的對象或者通過對象的關係找出來。

pojo對象屬於對系統的靜態描述。它應該是名詞，不應該是動詞或者其他。動詞、類型或者狀態等應該是演算法類型的對象，許可權應該是AOP考慮的，在後面的漫談里還會詳細提到。

目的

對領域的客觀描述反應。比如說：教育領域，農業領域，電商領域，零食領域等。這些只要領域背景沒有變化，就會是客觀穩定的。當然不同的產品的商業模式對同一個領域的理解也會不同，這些是會經常變化的，但是通常也只是體現在流程、類型、演算法、功能等上面，這些並不影響pojo對象。

• 所有人在溝通的時候理解一致
• 每個對象職責單一、明確、不可替代

屬性分類

為了快速區分屬性，並且快速找到真正的pojo對象和屬性。這些屬性可以在產品里的新增、詳情、列表等功能里得到體現。

自描述

一般體現出來的就是手動輸入。比如：名稱，標題等。

關聯

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

冗餘

方便查詢，減少複雜度。一般有以下情況：

• 一旦生成不會變化的，可以考慮冗餘，因為這樣可以減少複雜度。
• 偏統計類。比如：視頻里冗餘評論數購買數。
• 為了減少不同類型表的依賴。

功能

個性化業務，純粹是為了做功能

只留自描述，這個很難。需要深層次瞭解領域。通過領域驅動設計。這樣可以通過面向對象，通過很少的關註點，對整個系統有個靜態的認識。而且還可以判斷出產品變更的時候對整個系統的結構（即數據存儲）有什麼影響。特別是出現新名詞的時候。

需要根據產品的實際情況來判斷這些屬性怎麼規劃。如果是想要快速、簡單，但是4種類型都放到pojo上，開發是最快的，但是同時肯定也是擴展性最差的。也需要根據產品的真實需求來判斷怎麼處理後面3種類型的屬性。

抽取步驟

很多童鞋打著面向對象的幌子乾著面向過程的事。在抽取名詞的時候同時又考慮演算法、流程、許可權等。這樣一來關註點幾何倍數增長，本來應該用於考慮pojo對象是否合理的時間更沒辦法充分得到利用。

很多童鞋想成一次就把對象抽取出來。實現上抽取比印象中還要複雜。所以建議的是分步驟，按部就班的去抽取才是最快的辦法。

枚舉

只是把產品里涉及到的所有名詞枚舉出來。
下麵是枚舉時的陷阱：

• 不要去通過自己的理解去修改名詞叫法
• 不要去忽略自己覺得不重要的名詞
• 不要考慮表怎麼存儲
• 不要考慮非名詞

這些陷阱很容易讓後期返工。

刪除

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

去重

必需確保每個名詞都是職責單一，不可替代的。
一般去重的特征如下：不同的名詞體現出來的屬性，功能和生命周期是一樣的，只是描述不同。
比如： 不同角色的人在對同一個名詞描述不同，他們在新增的時候屬性相似度非常高，流程也特別像。

一般的反問自己或者產品：

• 它們的不同點在哪？
• 如果改一個地方，另一個地方會不會需要同時修改？
• 如果把它們做成一樣會有什麼問題嗎？

添加

• 在描述一個概念的時候，必須通過非常多其他對象，而且經常提。
• 雖然產品沒有提過，但是在實施的時候發生有很多對象有一樣的特性。常見情況：
  • 一個列表涉及到非常多的名詞，但是列表本身產品並沒有體現概念。
  • 不同的名詞，他們的屬性很雷同，而且生命周期幾乎是一樣的，有種幾條平行線的感覺。比如說：同樣要新增、發佈、審核等

聚合

把屬性名詞聚合到對象名詞里。這裡務必確認只放自描述屬性。其他的屬性暫時不考慮，因為可以很方便的通過關係來描述，而且這個也經常會變化。

陷阱

如果有以下的情況說明對象分析的不夠合理，後面很容易返工，請務必重視。

單方面描述

有一方有一直在說，但是另一方從來不提。說明這裡缺少重要名詞。

描述不一致

在描述同一名詞的時候，往往需求進一步翻譯。
這樣可能會出現的問題是：

• 溝通和維護成本增加
• 很可能缺少重要信息或者說關係理解的不對等。

組合描述

• 用多個詞來描述一個概念。需要一個新詞。
• 一個概念沒有具體自描述，而是關係出來的，但是又是溝通描述時經常出現。

推薦書單

• 《UML基礎，應用與案例》
• 《領域驅動設計》