Shouldn't in the following model an Address be a Value Object? - domain-driven-design

Question

From How are Value Objects stored in the database? :
Assume that a Company and Person both have the same mail Address.
Which of these statements do consider valid?
   1."If I modify Company.Address, I want Person.Address to automatically get those changes"
   2."If I modify Company.Address, it must not affect Person.Address"
If 1 is true, Address should be an Entity
If 2 is true, Address should be a Value Object.
Shouldn't in the above model the mail Address be a Value Object, since even if Company and Person have same mail, this mail still doesn't have a conceptual identity?
In other words, if initially Company and Person share initial.address#gmail.com, but then get new mail new.address#gmail.com, then we can argue that mail address initial.address#gmail.com itself didn't changed, instead Company and Person replaced it by new.address#gmail.com ?
Thus to my understanding a mere fact that Address is shared shouldn't be enough to give it personality (ie identity)?!
Thank you

Answer 1

Yes, your understanding is correct. Address should almost always be a value object, since in most domains, the address is indeed just a value.
The fact that a Company and a Person have the same Address today does not mean that if one changes, the other should change too. If such a relationship exists, it should be modeled through an explicit constraint rather than by making Address an entity.
Eric Evans talks about this in his excellent book on Domain-Driven Design and even provides a specific example where Address might be an entity -- the postal service, whose domain revolves around addresses, and where the identity of individual addresses is important.

Answer 2

Actually, the mail has a conceptual identity. The problem is that you aren't really modeling the e-mail address, but the Contact Information of a Person and/or the Contact Information of a Company.
Continuing with the topic, value object vs identity object is more an implementation decision rather than a "absolute truth".
You could use an immutable value object and when you tell the system "change address a for address b" search for all instances of address A in both person and the company, and update them to point to address b now. (or you could just update a single one of them).
Using a non-value Contact Information object is more powerful.
With:
Contact Information
{
string email;
}
You could actually have both person and company pointing to the same Contact Information object, so when you update one, you update the other too. Or you could have each of them point to a different Contact Information object, so when you update one, you don't modify the other...
BTW: e-mail has conceptual identity, since changing the e-mail address is actually what google did to me last week, when they changed my e-mail address from ending in #googlemail.com to #gmail.com... So if someone had my e-mail for both me and my company, just one update just change both instances, since in that ocassion my e-mail address changed itself... If on the other hand, I start using a different e-mail address, what changes is my contact information... My old e-mail address would still exist and be the same.
My advise is to model everything with identity, unless it's an extremely well object of a domain which you want to optimize an use as a value object for whatever reason (such as numbers, strings, etc...). But remember that it's usually a implementation decision, not something of the domain.

Answer 3

This is a classic case of taking something out of context.
The original question (How are Value Objects stored in the database) wasn't questioning the validity of the model, and my example wasn't to highlight these issues either. My answer was about Persistence vs Entity/VO.
I used the example of Customer, Person, and Address purely so that I could share the same Ubiquitous Language with the OP (I didn't have time to think up a better example).
I would follow casablanca's advice on this one (upvoted)