Value Object in DDD?

Question

Software design

I still don't fully understand the essence of this section in DDD.
1 - when creating an Entity, we make EntityId
2 - if we say we have an Entity called Product, it has 3 fields, id / name / price, then for other name and price fields we also create Entities, ProductName and ProductPrice.
I want to note that we cannot update, only create new ones. If in the case of ProductPrice, we plant the product_price_id in the product table and, thanks to the mapping, we will return the ProductPrice, whose id is indicated in the product table.
This was done in order to summarize everything. That is, we can use this ProductPrice in other products, it gives more control. We can treat the price of a product as an object.
But here is the question, the first thing I don’t understand is why ProductId, because we can’t use it in other Entities, and it doesn’t give anything special except as a load on the program logic.
So why is it then?
On the second:
1 - is it worth using this approach? How strong?
(when we plant ProductName / ProductPrice as new Entities)
2 - In fact, we have a unique product name, we cannot use it like EntityId in other entities, so why should we take it out as ProductName entity?
3 - What if we break the whole entity into sub-entities, let's say ProductId will have 15-20 more fields in which we will simply write numbers, links, mapping to sub-entities. There will be something like ProductName, ProductDescription, ProductCategory, etc.

Is it worth it to do so? Why and why? How to determine what should be taken out into a separate entity and what should not?

Examples of Value Objects are numbers, text strings, dates, times, a person's full name (composed
of first name, middle name, last name, and title), currencies, colors, phone numbers, and postal
addresses.

Answer 1

You have already answered but I want to make a remark.
I don't think matperez is 100% right. The fact is that the product may not be an entity, and may not contain an identifier, since everything depends on the business logic. From your example, given that there is only one use case (use case), namely, the creation of a product, and if this is the only logic of your business and you duplicate it with a new ID when creating a product with the same name, then the product is more like an aggregate with the main root in the form of a Value Object.
You have trouble understanding an Entity and a Value Object, and you call them all the same. This is very important to understand.
And finally, let me remind you that the mapper can return the necessary data to you even without converting the entire domain in essence. And best of all, for the time of modeling your domain, forget about the infrastructure altogether, and bring the domain to mind.