Many objects do not have their own identity. An example are windows with the same dimensions and the same way of opening and fixing, which do not differ from each other. I do not pay attention to exactly which ones will be mounted on each of the floors in the house. A child drawing a picture with a choice of two markers with the same color and shape, he does not care which one will choose.
In the domain, Eric Evans in the book “Domain-Driven Design Tackling Complexity in the Heart of Software” described this problem in such a way that the value object answers the question “what do they do?“. Unlike the entity, where we provide information about “who or what they are?“. These objects can be a component of another object. The house has many window frames consisting of the same size. Each of them has a window, which in turn can be incorporated into larger elements as a wall object.
The Value Object can refer to an entity. For example, by designating a route from Krakow to Wroclaw in the web application, we get this route as a value object with a reference to three entity objects (two cities and a highway).
By specifying an object thinking only of its attributes as an element of the model, we create a value object. Treating it as a non-mutable object – attributes should not change while the system is running – you should not give it identification features, such as key ID.
The value can be represented by the address. For example, if the user has such fields as: street, city and zip code, they should create a separate value object of the address of residence and refer to the entity with the user.
Summary
Value object has similar properties to the entity, but does not have its own identity.
