Types of the business domain that do not form identifiable entities but only specific values are called value objects. Value objects are preferably immutable and therefore reusable, since the content can't change. Java enumerations are a good example of this. Any objects where identity doesn't matter will be realized as value objects. For example, for Java enumerations it doesn't matter which instance of Status.ACCEPTED is returned, here there is even only one enum instance which is used in all places. The same is true for a lot of types in the domain, such as addresses. As long as the value of the address pointing to 42 Wallaby Way, Sydney remains the same, it doesn't matter which address instance we refer to.

Depending on whether the set of values is finite, value objects are either modeled as enumerations or POJOs, ideally immutable. Immutability represents the concept of value objects and reduces the probability of potential errors. Changing a mutable object that is shared by multiple locations can lead to unplanned side effects.

As value objects are not identified directly they also won't be persisted and managed directly in a database. They certainly can be persisted indirectly, as part of a graph of objects, referenced from an entity or aggregate. JPA supports managing persistence of objects that are not entities or aggregates.