Value Object in DDD?

I don't quite still understand the essence of this section in DDD.

1 - when creating the Entity, we do EntityId
2 - if we say we have a Entity called Product, it has 3 fields, id / name / price, then for other fields name and price we are also going to create more Entities, ProductName, and ProductPrice.
I want to see what to update we can not only create a new one. If in the case of ProductPrice, we put in the additional info table product_price_id and thanks to the mapping we will return ProductPrice id that is specified in the product table.

This is done in order to summarize all. That is, we may use the ProductPrice in Durga products, gives you more control. We can handle price additional info as the object.

But here's the question, first I do not understand why the ProductId, because we can't use it in the other Entity, and nothing special except it does not give as the load on the logic of the program.
Then why do it?

The second:
1 - whether to use this approach? How much?
(when we put ProductName / ProductPrice as a new Entity)
2 - In fact, we have the name of the product is unique, we can't use as the EntityId in other entities, therefore, why we take it as ProductName essence?
3 - What if we divide the entire entity into sub entities, let's say a ProductId will be another 15-20 fields in which we just write numbers, links, mapping to the sub entity. Would be something like ProductName, ProductDescription, ProductCategory, etc.

Is it a good idea? And why? How to determine what should be brought in a separate entity and what is not?

Examples of Value Objects are numbers, text strings, dates, times, a person's full name (composed of
of first name, middle name, last name, and title), currencies, colors, phone numbers, and postal
June 10th 19 at 16:27
1 answer
June 10th 19 at 16:29
You have already answered but I want to make a comment.
I don't think 100% right. The fact that the product may not be the essence, and does not contain identifier, as it all depends on the business logic. From your example given that there is only one SW case (use case), namely the creation of the product, and if this is the only logic of your business and you when you create a product with the same name duplicate it with the new ID, then the product is more like Assembly with the main root in the form of a Value Object.

You have trouble understanding the entity (Entity) and of a value object (Value Object), and you all call as one only. It is very important to understand.

And finally, let me remind you that you maper may return the desired data without converting the whole domain in fact. And best of all at the time modeling your domain, forget about the infrastructure, domain and bring to mind.

Find more questions by tags Designing softwareProblem-oriented design