[[Value Object|Value Objects]] represent immutable domain concepts identified by their content, used to describe or quantify other domain concepts. In contrast, [[Entity|Entities]] represent mutable concepts maintaining consistent identity, and responsible for protecting invariants and enforcing business rules. To preserve immutability, prevent identity leakage, and avoid [[Accidental complexity]], Value Objects should remain independent of Entities. Unlike Entities, Value Objects are immutable, and separating them prevents side effects, such as changes in an Entity affecting a dependent Value Object. Since Value Objects are identified by their content and Entities by unique identifiers, this separation ensures clear distinctions in how uniqueness and sameness[^1] are managed. Referencing Entities within Value Objects can complicate serialization, comparison, and lifecycle management. Value Objects tend to be lightweight and short-lived, while Entities have longer lifecycles and more complex behaviors. Although referencing an Entity from a Value Object may seem convenient, especially when they are closely related, it’s better to avoid this. Instead, pass only the necessary data from the Entity to the Value Object. If interaction with an Entity is required, delegate this to a [[Domain Service]]. When dealing with multiple data sources, extract the necessary information into a new Value Object to avoid direct dependencies and keep the design clean. Rather than embedding an Entity, pass its unique identifier to the Value Object, preserving the relationship while maintaining the lightweight nature of the Value Object. External mappers or converters can transform Entity state into a Value Object, enabling the use of Entity data without introducing [[Tight coupling]]. [^1]: [[Identity is about defining uniqueness and sameness]]