If you have a method named ReplaceHomeAddress you aren’t maintaining a collection. Maybe you are internally, but that’s no different than having a HomeAddress property.

“If you tried to edit one of the addresses respecting some immutable Value Object oriented thinking, you would clear the collection, find (somehow) the one you intended to edit, replace it along with all the others.”

This doesn’t make sense to me, why am I clearing the collection. Lets say I want to replace the home address, I’d just call ReplaceHomeAddress and it’d replace the Address with an AddressType of Home or it would replace the appropriate item in the dictionary (assuming it was a dictionary). If, when identifying an address, I’m only interested in one piece of its data (Home vs. Work) then thats fine, can’t think why its a problem?

“If you were to take some money out of your wallet, you would subtract from the Value Object, not remove an instance of the Value Object from a collection.”

The wallet is an entity so why not just subtract money (value objects) from it?

“You don’t care if you have five ones or one five, you just care that you have five.”

If it isn’t important to the system then thats fine, it is important in real life if you have a $5 note and you need to hand over $2 of course.

“If I am maintaining a collection of Addresses, I do actually care that each is different – the trick is to find out why. In my case I care because the Customer has an address history and I wish to maintain that history”

I agree with this, relationship objects are very much under-explained in DDD (http://colinjack.blogspot.com/2008/10/ddd-making-meaningful-relationships_28.html). However as well as temporal aspects you probably also care about different types of addresses, just so happens you’d handle them differently.

The example I’d give is tags, or keywords, or the like. I can choose to refer to them in my ‘blogpost’ entity as a string array, but they’re still not individually important. I likely would just replace them all upon update rather than specifically editing one in the collection, because I don’t care that much about the keyword itself so much as I care about the fact that a given blogpost is described.

Scoped identity is still identity. Sounds like you have a collection of ColorPreference Entities in a User Aggregate. You still access ColorPreference through the Aggregate (not through the repository), similar to how you would do it “by index”.. “By index” doesn’t really work anyway though. Consider sort order – it will change from screen to screen. The counter-argument is, “yeah but I specify the index on the screen, so that even if it’s sorted differently I still know which one is which.”

The counter-counter argument is a) that’s an identity even if you are shoving it into an index and b) whenever you care about a specific instance, “which one is which”, you have an Entity!

You also have to consider whether or not this “value object” is really an entity in disguise.