做产品会设计到很多的领域，但是这些领域中出现的概念往往是比较稳定的，而他们的变化点在于由不同的产品（这里指在这个领域做产品的人）
会根据他们对这个领域以及互联网的理解去设计他们自己的产品规划（流程，规则），作为需求分析的人员来说大部分情况是我们是基于产品的原型，prd进行
需求分析和设计的，这里面其实我们应该做的第一个工作就是找出这个领域中不变的领域概念（领域名词）。
下面我们就来介绍一下俺们大神使用面向对象的方式抽取领域名词的步骤。
需要知道
- pojo对象属于对系统的静态描述。它肯定是名词。
- 抽取领域名词的最终目的是为了数据存储。
这些名词一定会转换后面我们系统中存在的实体，表，所以它也是整个应用或者产品的数据来源就确定。
比如一个页面或者功能需要使用什么数据就可以快速找到对应的对象或者通过对象的关系找出来。
确定对象列表
穷举名词
如果有原型就在原型中查找所有名词，从左到右从前到后一个名词都不放过，
把你所有认为可以作为备选的全部列出来。
如果没有原型就在客户或者产品的口中获取到反复出现的名词。
注意：
不要去通过自己的理解去修改名词叫法
不要去忽略自己觉得不重要的名词
不要考虑表怎么存储
不要考虑非名词
这些陷阱很容易让后期返工。
删除
删除和产品（领域）无关的名词。
比如：文案可能出现了故宫或者平台名等和本领域无关的名词。
去重
必需确保每个名词都是职责单一，不可替代的。
如果两个名词在概念上比较相似，但是表面词语不太一样的可以将这两个词归为一类，删除多余的名词。
一般去重的特征如下：不同的名词体现出来的属性，功能和生命周期是一样的，只是描述不同。
比如： 不同角色的人在对同一个名词描述不同，他们在新增的时候属性相似度非常高，流程也特别像。
一般的反问自己或者产品：
- 它们的不同点在哪？
- 如果改一个地方，另一个地方会不会需要同时修改？
- 如果把它们做成一样会有什么问题吗？
聚合
把属性名词聚合到其他跟内聚的对象里。
有一些名词都是可以分到一个组中去的，比如：程序员，人事，cto,都是公司的员工，所以可以分到员工对象中去。
这里只放自描述属性，其他的属性暂时不考虑，因为可以很方便的通过关系来描述，而且这个也经常会变化。
添加
在描述一个概念的时候，必须通过非常多其他对象，而且经常提。
虽然产品没有提过，但是在实施的时候发生有很多对象有一样的特性。常见情况：
- 一个列表涉及到非常多的名词，但是列表本身产品并没有体现概念。
- 不同的名词，他们的属性很雷同，而且生命周期几乎是一样的，有种几条平行线的感觉。比如说：同样要新增、发布、审核等
确定这个名词的职责
在做项目中我们难免会做超出我们认知范围内的领域知识，
找产品和客户搞清楚这些名词的含义，可以帮助我们确定这个名词的描述。
比如：课表：是学生报名之后根据所报年级的课产生的上课安排。
到目前为止领域中的核心名词都抽取出来了，也确定了这个名词的含义，也就是说我们的对象列表以及对象的职责也就确定了。
下面就是该找这个对象的属性了。
确定对象的属性
属性分类
一个对象的属性大致分为几个类型：
自描述属性，关联属性，冗余属性，功能性属性
自描述属性
一般体现出来的就是手动输入。比如：名称，标题，描述等等
关联属性
有依赖来源，即在别的地方是手动输入，但是当前功能是选择。比如：选择地区，选择类型
冗余属性
方便查询，减少复杂度。一般有以下情况：
- 一旦生成不会变化的，可以考虑冗余，因为这样可以减少复杂度。
- 偏统计类。比如：视频里冗余评论数购买数。
- 为了减少不同类型表的依赖。
功能性属性
个性化业务，纯粹是为了做功能
建议：
只留自描述，这个很难。需要深层次了解领域。通过领域驱动设计。这样可以通过面向对象，通过很少的关注点，对整个系统有个静态的认识。而且还可以判断出产品变更的时候对整个系统的结构（即数据存储）有什么影响。特别是出现新名词的时候。
需要根据产品的实际情况来判断这些属性怎么规划。
如果是想要快速、简单，但是4种类型都放到pojo上，开发是最快的，
但是同时肯定也是扩展性最差的。
也需要根据产品的真实需求来判断怎么处理后面3种类型的属性。
结束语
这些都是和我们大神交流学习得来的，看起来会有一些晦涩难懂，后面会根据一个实际项目进行举例。
最后附上大神博客园：
http://www.cnblogs.com/ansn001/