A value object is a developer-defined type whose instances are identified by their values, not by an independent persistent identity. In a persistence model, it belongs to an entity: it has no persistent identifier of its own, cannot be shared by multiple owners, and lives as long as its owner does. Address and MonetaryAmount are examples; String and BigDecimal have similar value-type semantics. section 5.1.2 section 6.0
Choosing the model for an address
Suppose two users live at the same address. If each user holds a separate Address instance that exists only as part of that user, Address can be a value object. Deleting one user can then remove that user's address without affecting the other. If both users must refer to one shared Address instance, Address needs entity identity and an independent lifecycle instead. section 5.1.2
In JPA, a developer-defined value object can be mapped as an embeddable component. For a User with homeAddress and billingAddress, the USERS table holds both addresses' columns in the user's row rather than storing each address as an independently identified entity. Saving or deleting the user saves or deletes its components; no separate SQL operation is needed for their lifecycle. Embedded attributes can also be overridden, and components can be nested. section 6.2.1 section 6.0
The schema diagram shows how one entity row contains the columns of its components, making their lack of separate identity visible. section 6.2.1
Lifecycle dependence alone is not a sufficient test. A Bid may depend on an Item yet still need entity identity if other objects must hold shared references to that particular bid. Decide whether an instance must be retrieved or referenced independently before choosing an embedded value object over an entity association. section 5.1.3 section 5.1.2
