漫淡物件導向 POJO物件

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

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

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

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

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

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

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

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

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

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

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

只是把產品裡涉及到的所有名詞列舉出來。

下面是列舉時的陷阱：

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

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

必需確保每個名詞都是職責單一，不可替代的。

一般去重的特徵如下：不同的名詞體現出來的屬性，功能和生命週期是一樣的，只是描述不同。

比如：不同角色的人在對同乙個名詞描述不同，他們在新增的時候屬性相似度非常高，流程也特別像。

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

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

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

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

在描述同一名詞的時候，往往需求進一步翻譯。

這樣可能會出現的問題是：