I know this question is from some years ago, but I’ve been dealing with a similar modelling problem at the moment, and perhaps it will be useful to someone else to see what alternative opinions are out there.

You’re right, this section is a bit misleading and contradictory, as so much time is spent in DDD indicating that the domain design shouldn’t be driven by persistence concerns.

If I’m taking a guess, what is actually being referred to is the immutable nature of Value Objects. In this example he talks specifically about the ordering of the Backlog Items. Value Objects are immutable, so changing the order of 1 Backlog Item could result in “significant number, even all, of the ProductBacklogItem instances to be deleted and replaced”.

So although technically still driven by the infrastructure, ultimately to retain order in a SQL solution, the Value Object must be mutable, and therefore not a Value Object. This problem doesn’t exist in an NoSQL solution where “Aggregate instances are typically serialized as one value representation for storage.” So you shouldn’t let persistence drive your design, but to allow re-ordering there is no way around not having the object be an Entity

This is where my own modelling problem came into the picture. If the order of the items is important, then I’ve been wrestling with the idea that those objects must be Entities… because if order is important, then identity must be important as well. ie. How do you re-order items if each one doesn’t have a specific identity? If order isn’t important, then it’s now just a collection/bag of values, and so now they are likely Value Objects.

The approach I’ve been considering is that the order should be maintained by an Entity, in this instance OrderedBackLogItem. But this entity contains a ProductBacklogItem Value Object and an ordering attribute.

Other alternatives are the the approach Vernon has taken (one Entity), or the collection itself is a Value Object, and so the entire ordered list is destroyed and re-created each time.

I’m still in two minds as to whether each item in a list must be an Entity if re-ordering is important.

The reason is that SQL databases store the objects in a relational way – items are stored in different table than aggregate root and they reference back to aggregate root by IDs. So using of MySQL requires to model items as entities that are persisted in separate table where they obtain primary id (with auto increment).

In key-value stores eg. MongoDB one can store the whole collection of items as part of the aggregate root. The items would not become separate entities (in its on table) and thus can be modelled as value objects.

Eg. Blog has Comments stored as collection within:

{
  _id: 1,
  title: 'Some title',
  body: 'Blog body',
  comments: [{
     person: 'John Smith',
     comment: 'First comment of the blog',
     created_at: new Date()
  },
  {
     person: 'Peter Jackson',
     comment: 'Second comment of the blog',
     created_at: new Date()
  }],
}