On page 382 of this book there is a passage talking about using value objects in aggregates, under the (entity) root. There is an example of
Product that, besides other values, contains a
Set<ProductBacklogItem> - collection of entities.
Now, Vernon tries to explain why
ProductBacklogItem is an entity and not a value object:
There are good reasons why ProductBacklogItem is modeled as an Entity rather than a Value. As discussed in Value Objects (6), since the backing database is used via Hibernate, it must model collections of Values as database entities. Reordering any one of the elements could cause a significant number, even all, of the ProductBacklogItem instances to be deleted and replaced. That would tend to cause significant overhead in the infrastructure. As an Entity, it allows the ordering attribute to be changed across any and all collection elements as often as a product owner requires. However, if we were to switch from using Hibernate with MySQL to a key-value store, we could easily change ProductBacklogItem to be a Value type instead. When using a key- value or document store, Aggregate instances are typically serialized as one value representation for storage.
I don't understand why the Repository implementation determines if some model is going to be an Entity or Value Object? If we go to the key-value store, we still may have ordering he is talking about.
Do you think this make sense?