Disclaimer: I think questions about DDD rarely have answers, but are encouragements for dicussions. So this is my opinion with all possible flaws and biases. This is not an answer. But if you really like my opinion, you can select it as the accepted answer... which would be the pragmatism you need to solve your problem :-)

I'll give you an example from my project: sports competition management. There is this concept of an age group, for example "female under 18". You could say that this is a Value Object because it is defined by its values (gender, maxAge, minAge) and has no life cycle. But I introduced an Id because I need to reference it in foreign keys and I didn't want to have 2 columns (gender and maxAge) in my database for referencing it. And a few years into the project, it was decided that the minimum age would be changed. Until then you had to be at least 16 to participate in this age group, but they lowered it to 15. So we changed that in the age_group table / AgeGroup ValueObject.

... so this was the second indicator (after having an Id) that it might not be a Value Object. And it turns out there is a 3rd one: more than one entity referencing the same instance. When we changed the minimum age, this meant that we also changed the minimum age for some competitions in previous seasons... not good!

There is lots of dicussions if a postal address is a Value Object or an Entity. There is good arguments for both opinions. But if 2 people live in the same house and person.address points to the same instance of Address for both persons, then it is an entity for sure.

An example for ValueObject with Id: a person can have more than one way to contact them. so there is person.contactInfos an array of ContactInfo which has a type ("email", "phone", etc.) and URL. For simplicity's sake, I gave them an Id just to make the ORM easier. But when I update a persons Contact Infos, or change the order, I just delete the old ones and create the new ones. Because that's what Value Objects are: disposable and exchangeable. For every Value Object instance in your application. You should be able to delete it and then create one with the same values, attach it to an entity and things are just the way as before.

To sum it up:

• I have no issues with a Value Object having an Id for technical reasons, but that Id must never be used. If you address a person's address via HTTP endpoint, it should be something like /person/{personId}/address and not /address/{addressId}.
• If more than one entity references the same Value Object, then it is no Value Object. Consider a monetary amount: combination of currency and amount. If you have some money transfer, then you will have a MonetaryDebit on one side and a MonetaryCredit on the other account. Both these entities have a MonetaryValue that represents the currency and amount. But it is different instances... just with same values.

For your problem, I suggest following decision path:

• If the model object is actually only a string, then it's a Value Object. Maybe just an Enum?

• If the same model object is referenced by more than one entity, then it's an entity. You might want to introduce the concept of "immutable entity with a Uniqueness Constraint" like my example of the AgeGroup that has a uniqueness constraint over gender + maxAge

• If your model object has an Id just to simplify ORM but is only attached to one entity and you can delete that instance and recreate it without any side effects, then it's a Value Obect with an Id.