产品或者服务由数据存储和数据计算组成。pojo对象就是用于数据存储。一旦确定后，整个应用或者产品的数据来源就确定。比如一个页面或者功能需要使用什么数据就可以快速找到对应的对象或者通过对象的关系找出来。
pojo对象属于对系统的静态描述。它应该是名词，不应该是动词或者其他。动词、类型或者状态等应该是算法类型的对象，权限应该是AOP考虑的，在后面的漫谈里还会详细提到。
目的
对领域的客观描述反应。比如说：教育领域，农业领域，电商领域，零食领域等。这些只要领域背景没有变化，就会是客观稳定的。当然不同的产品的商业模式对同一个领域的理解也会不同，这些是会经常变化的，但是通常也只是体现在流程、类型、算法、功能等上面，这些并不影响pojo对象。
- 所有人在沟通的时候理解一致
- 每个对象职责单一、明确、不可替代
属性分类
为了快速区分属性，并且快速找到真正的pojo对象和属性。这些属性可以在产品里的新增、详情、列表等功能里得到体现。
自描述
一般体现出来的就是手动输入。比如：名称，标题等。
关联
有依赖来源，即在别的地方是手动输入，但是当前功能是选择。比如：选择地区，选择类型。
冗余
方便查询，减少复杂度。一般有以下情况：
- 一旦生成不会变化的，可以考虑冗余，因为这样可以减少复杂度。
- 偏统计类。比如：视频里冗余评论数购买数。
- 为了减少不同类型表的依赖。
功能
个性化业务，纯粹是为了做功能
只留自描述，这个很难。需要深层次了解领域。通过领域驱动设计。这样可以通过面向对象，通过很少的关注点，对整个系统有个静态的认识。而且还可以判断出产品变更的时候对整个系统的结构（即数据存储）有什么影响。特别是出现新名词的时候。
需要根据产品的实际情况来判断这些属性怎么规划。如果是想要快速、简单，但是4种类型都放到pojo上，开发是最快的，但是同时肯定也是扩展性最差的。也需要根据产品的真实需求来判断怎么处理后面3种类型的属性。
抽取步骤
很多童鞋打着面向对象的幌子干着面向过程的事。在抽取名词的时候同时又考虑算法、流程、权限等。这样一来关注点几何倍数增长，本来应该用于考虑pojo对象是否合理的时间更没办法充分得到利用。
很多童鞋想成一次就把对象抽取出来。实现上抽取比印象中还要复杂。所以建议的是分步骤，按部就班的去抽取才是最快的办法。
枚举
只是把产品里涉及到的所有名词枚举出来。
下面是枚举时的陷阱：
- 不要去通过自己的理解去修改名词叫法
- 不要去忽略自己觉得不重要的名词
- 不要考虑表怎么存储
- 不要考虑非名词
这些陷阱很容易让后期返工。
删除
删除和产品（领域）无关的名词。比如：文案可能出现了故宫或者平台名等和本领域无关的名词。
去重
必需确保每个名词都是职责单一，不可替代的。
一般去重的特征如下：不同的名词体现出来的属性，功能和生命周期是一样的，只是描述不同。
比如： 不同角色的人在对同一个名词描述不同，他们在新增的时候属性相似度非常高，流程也特别像。
一般的反问自己或者产品：
- 它们的不同点在哪？
- 如果改一个地方，另一个地方会不会需要同时修改？
- 如果把它们做成一样会有什么问题吗？
添加
- 在描述一个概念的时候，必须通过非常多其他对象，而且经常提。
- 虽然产品没有提过，但是在实施的时候发生有很多对象有一样的特性。常见情况：
- 一个列表涉及到非常多的名词，但是列表本身产品并没有体现概念。
- 不同的名词，他们的属性很雷同，而且生命周期几乎是一样的，有种几条平行线的感觉。比如说：同样要新增、发布、审核等
聚合
把属性名词聚合到对象名词里。这里务必确认只放自描述属性。其他的属性暂时不考虑，因为可以很方便的通过关系来描述，而且这个也经常会变化。
陷阱
如果有以下的情况说明对象分析的不够合理，后面很容易返工，请务必重视。
单方面描述
有一方有一直在说，但是另一方从来不提。说明这里缺少重要名词。
描述不一致
在描述同一名词的时候，往往需求进一步翻译。
这样可能会出现的问题是：
- 沟通和维护成本增加
- 很可能缺少重要信息或者说关系理解的不对等。
组合描述
- 用多个词来描述一个概念。需要一个新词。
- 一个概念没有具体自描述，而是关系出来的，但是又是沟通描述时经常出现。
推荐书单
- 《UML基础，应用与案例》
- 《领域驱动设计》