I'm studying DDD from the books of Eric Evans and Vernon. During the reading I came across the Value Object implementation, I even understood the concept but could not abstract into a real situation within a domain.
I joined the following tutorials and one of them more confused than it helped:
p>The question is how to identify a value object and when to use it?
In my opinion DDD tends to complicate what is simple. These classes call value objetct which are usually called the value types and the entities that are called types by reference. Learn more about this at question about C # .
Types by value have their own identity and any change in their value changes the identity, that is, another object. Types by value do not have associated objects, the object is treated directly in its storage location.
Types by value are usually immutable and small . They represent something unique, like quantifications. Non- scalars types of any language are usually value objetcs .
There are cases of types that are by reference as a facilitator, but they remain value objects , this is the case of string .
Dates are often great examples. Codes, miscellaneous monetary values, points, identifiers, etc.
So young, it's not that complicated or mystical like that ...
To help, the subject of DevMedia quotes wikipedia ... and still says nothing with anything ... ok ...
Think simply, in the IMUTABILITY of the object. The value object therefore DOES NOT CHANGE in the context of your application;
What if you think about a list of services, for example? services
See that the services you make available to include in an invoice do not usually change, right? (hardly the government changes this type of list)
@JcSaint, think of software lighter, and more fluid. The software we write primarily serves us, programmers.
; -)
Very briefly is the following:
See the following:
cliente: {
id: 1,
nome: "Thiago Lunardi",
sites: [
{ url: "http://thiagolunardi.net", tipo: "blog" },
{ url: "https://github.com/thiagolunardi", tipo: "github" },
]
}
Client has identification, but Sites no longer have ID, they are just values.
A value object works with aggregation. Two important rules: 1) They have no identity; 2) They are immutable;
What this means: If you have a client and it only has one full address, and the address only exists as long as the client exists ... this is an aggregation so it can be a value object. If you use a Relational Database, a value object is intrinsically within the parent entity, ie, address (street, street, neighborhood, zip code, etc.) lives within the Customer Entity. However, if your business allows the client to have more than one address, then we will no longer have the exclusivity of the domain and it can not be a value object, but a class or entity participating in a relationship and with that will have an ID and not be immutable.