DDD-实体

在现有开发方式中，开发人员和设计人员更关心的是数据库表的设计，列的属性以及表之间的关联关系（外键），每个类就只有get和set方法，没有具体的行为，也就是DDD中经常讲的贫血模型。
今天用这篇文章来记录学习实体的概念。

为什么要使用实体

当需要定义一个对象的个性特征，或者区分不同的对象时，就引入了实体的概念。
一个实体是一个唯一的东西，并且在相当长的一段时间内持续地变化。可以对实体做多次修改，因此一个实体对象可能和它先前的状态是不一致的。但是这个对象的唯一标识也就是身份标识是不变的。唯一的身份标识和可变性也是实体和值对象的区别之处。

唯一标识

在实体设计早期，我们将刻意地把关注点放在能够实现实体身份唯一性的主要属性和行为上，同时还将关注如何对实体进行查询，另外，刻意地忽略掉那些次要的属性和行为。
在设计实体时，首先需要考虑实体的本质特征，特别是实体的唯一标识和对实体的查找，而不是一开始便关注实体的属性和行为。只有在对实体的本质特征有用的情况下，才加入相应的属性和行为。
唯一标识的生成方式：

• 用户手工输入
• 程序内部通过算法生成，如guid
• 通过数据库的方式自动生成
• 通过另一个限界上下文生成
  在现有系统中，一般都是通过guid的方式来生成唯一标识。
  而且标识的生成时间一般越早越好，这样在后面发布领域事件或者调用其他领域服务的时候，可以通过唯一标识将当前实体确定下来。

发现实体及其本质特征

在实现DDD一书中，是通过介绍user和tenant两个类的关系来讲解实体的。

• User存在于某个Tenant之下，并受该Tenant控制
• 必须对系统中的User进行认证
• User可以处理自己的个人信息，包括名字和联系方式
• User的个人信息可以被其本人和Manager修改
• User的安全密码是可以修改的

User和Tenant是独立存在的，而且是具有不同的属性的，并且随着时间的变化，属性是可以变化的，因为User和Tenant是实体，而不能设置成值对象。

挖掘实体的行为

通过实体的角色和职责来挖掘。
在面向对象编程中，通常由接口来定义实现类的角色。在正确设计的情况下，一个类对于每一个它所实现的接口来说，都存在一种角色。如果一个类没有显式的角色——该类没有实现任何显式接口，那么在默认情况下它所扮演的既是本类的角色。
角色接口最实用之处就是通过接口，我们可以将实现细节隐藏起来，从而不至于将实现细节泄露给客户端或者调用者。