什么是实体类？
实体类
实体类是概念性的数据密集类-他们的主要目的是存储数据并提供对这些数据的访问。
在很多情况下，实体类是持久的，这意味着数据是长久存在的，并需要存储于文件或者数据库中。
面向对象的静态建模和频繁用于逻辑数据库设计的实体关系建模的主要不同是，尽管两种方法都对类、类属性、类间关系建模，
但面向对象的静态建模还允许规定类的操作。
以上摘取于《软件建模与设计 UML用例模式和软件体系结构》[p.80]。
主要由标识定义的对象被称作Entity。Entity(实体)有特殊的建模和设计思路。
他们具有生命周期，这期间他们的形式和内容可能发生根本改变，但必须保持一种内在的连续性。
为了有效地跟踪这些对象，必须定义他们的标识。
他们的类定义、职责、属性和关联必须由其标识来决定，而不依赖于其所具有的属性。
以上摘取于《领域驱动设计 软件核心复杂性应对之道》[p.58]。
这两片摘取都在说明什么是实体类，数据密集型、持久化、具有生命周期、标识定义。
但是都没有将实体的本质讲透彻，尤其是第二篇，好像加了个标识就是实体了。
实体类是面向对象的静态建模。但是实体本身又是一个概念，所以我们需要先搞懂什么是实体。
实体概念
具有具体而真实的形态或结构的事物，能够为人们所感知与亲手接触。
从数据处理的角度看，现实世界中的客观事物称为实体，它是现实世界中任何可区分、可识别的事物。
实体可以指人，如教师、学生等，也可以指物，如书、仓库等。
它不仅可以指能触及的客观对象，还可以指抽象的事件，如演出、足球赛等。
它还可以指事物与事物之间的的联系，如学生选课、客户订货等。
其实上面说的很明白了，现实世界中的客观事物称为实体。
所以并不是类中有没有标识就是实体。我举个例子，比如：电商系统中的收货地址，一个顾客可以管理多个收货地址，
为了更新某一个收货地址会为收货地址添加一个标识。
但是在商品订单中也有收货地址，但是他并不关心有没有标识，被大家创建成为值对象，附着在订单类上。
同一个收货地址类就因为有没有标识就被称为是实体或者值对象是错误的。因为他就是实体。
就像有些文献建议将一个事物先创建为值对象，在需要标识的情况下再修改为实体一样。
其实值对象是实体的一部分，他并不能独立且有意义的存在。所以并不存在将一个事物建立成技术上的实体或者值对象的困扰。
将一个实体上的一些属性抽象成一个值对象是因为更具体更清晰更符合现实。而不是因为标识。
总结
领域驱动设计中说的实体和值对象他们都是现实概念中的实体。
只有理解他们都是现实概念中的实体，才能更清楚的使用技术来抽象实体和值对象。
在JPA中使用@Entity注解来表示实体，使用@Embeddable来表示值对象。
所以我希望你能通过这篇文章来明白不是因为使用@Entity或者@Embeddable注解来区分实体或者值对象。
也不是因为XxxEntity,XxxValueObject这种类的命名方式来区分实体或者值对象。
这些方式更像是显式的UML中的构造型(stereotype)。
如有问题请加QQ群讨论：
