实体最大的特点是拥有唯一标识符，这个标识符贯穿整个软件的生命周期，不随业务流程和状态变更后更改，在领域模型中以领域对象DO的形式存在。 如下代码示例：人事领域里的人员考勤子域，考勤里面有员工对象，员工需要通过上班打卡，下班打卡完成一个完整的考勤行为，这个员工就是一个实体，因为每个人在公司都有工号，是标识这个人的唯一ID，不管他去上海还是北京出差打卡，他的员工ID都不会变化。 同时实体还会包含跟考勤相关的上班打卡和下班打卡方法，是一个充血模型。
/**
* 人员实体
* @author test11
*/
public class Person {
//人员id
private String id;
//姓名
private String name;
//地址
private Address address;
//上班打卡
private void goWork(){
}
//下班打卡
private void leaveWork(){
}
}
二、值对象如上代码示例中，员工的信息由人员id，姓名，所在的省，市，街道组成，我们可以将省，市，街道抽象出来一个Address，构成一个地址的属性集合，这个集合的名称就是地址值对象。 所以值对象就是一个属性集合，将不同的关联属性组合成了一个概念整体，具有整体概念和不可修改的特性。
/**
* 地址值对象
*/
public class Address {
//省份
private String province;
//城市
private String city;
//街道
private String street;
}
三、实体和值对象实体和值对象都是微服务底层最基础的领域对象，实现领域最基本的业务逻辑。 实体和值对象都是若干属性的集合，实体一般是带有业务含义的的对象，具有业务属性，业务行为和业务逻辑。 值对象也是若干属性的集合，但他只有数据初始化操作，不涉及数据修改，基本不包含业务逻辑。 值对象是属于实体的一部分，如果值对象是单一属性，则直接定义为实体的属性，如果值对象是属性集合，则将他设计为值对象类，值对象没有ID，会被实体整体引用。
四、实体和值对象的数据库形态 实体：将领域模型映射到数据模型时，一个实体（DO）可能对应0，1，多个数据库持久化对象（PO），大多数情况下DO和PO是一对一的关系，当DO只是暂住内存时，也可以不需要持久化。当用户和角色两个实体合并成权限实体时，一个DO则对应了多个PO。当用户实体和订单实体合并到一张表中时，这两个DO的生成需要一个PO的拆分，这是多对一的关系。 值对象：值对象的数据库设计大都采用了反范式，实体对象的属性值和值对象的属性值集合以JSON形式保存在同一个数据库表中。 上面的人员和地址的对应关系，设计数据库表时可以有三种方式： （1）把地址值对象的所有属性加到人员实体表中：这种设计方式会破坏地址的业务含义和属性完整
（2）创建人员实体的表，关联地址实体表：增加了不必要的实体和表
（3）实体对象的属性值和值对象的属性值集合以JSON形式保存在同一个数据库表中：数据建模时，可以将值对象的属性集合嵌入到实体表中，保留对象的业务含义，同时减少了表的设计，一般是将值对象序列化成大对象JSON串后，嵌入到实体表中的
基于第三种方式的领域模型落地，现在许多数据库都开始支持基于JSON串的CRUD操作了，当然，类似这样值对象的设计，多了可能会使实体堆积一堆缺乏完整意义的属性。
但是值对象不可变，在并发环境下获取的永远是相同的对象，不会被修改，所以值对象可以被多个实体并发引用，所以高并发场景下的领域对象一般优先设计为值对象而非实体，可以保证线程安全。
值对象还有一个重要作用，以数据冗余的方式记录业务发生那一刻的数据，比如用户聚合中包含了用户（聚合根，也是实体）和地址值对象，订单生成那一刻，用户和地址信息以JSON的方式冗余进订单数据中，这样避免了订单聚合每次都通过调用用户的聚合根ID获取最新用户信息和地址，解耦了用户聚合和订单聚合，同时用户实体和地址值对象也以冗余的方式，记录了业务的快照数据，还原业务发生前后的场景。
五、贫血模型和充血模型 贫血模型：Spring的bean就是一种贫血模型，领域被用来作为属性存储的载体，而没有实现具体方法，比如教育领域的校长，只会记录他的年龄，职级，工作年限，而不会有他的一些行为的方法实现，单单用来作为属性的存储。 充血模型：实体不止包含对象的属性，也包含他对应的行为的方法实现，而不止仅仅作为属性存储的载体。