A value object is an object where its identity is solely defined by its state. Value objects are called so because they are values, and values do not change. If a value changes its value, well, then it is not longer the same value. So, one important design rule for value objects is to make them immutable by default. If one wants to change the state of an existing value object, a new value object should be created. If the application has no more use of the obsolete value object, it should be discarded. Immutable objects are inherently thread-safe.
Typical examples of a value objects are Specifications and Addresses.
An entity object should at all time have a final and unique entity ID. The entity ID defines its identity.
Entity objects are mutable by default, as they cannot be discarded as easily as value objects can.
Typical examples of entity objects are Customers and Orders.
Here is Domian's entity interface:
public interface Entity {
java.io.Serializable getEntityId();
}
No rule without an exception... Some objects are obviously entities, but their time of relevance can be more or less limited.
Typical examples of transient entity objects are "timestamped value objects" like work tickets. Other examples are all kinds of derived entities. Derived objects can be regenerated on demand, and therefore should be regarded as transient.
One important design rule regarding transient entity objects is to put them in volatile repositories. Only real entities should be put into persistent repositories.