DDD: Help me further understand Value Objects and Entities

There are several questions on this, and reading them isn't helping me. In Eric Evans DDD, he uses the example of address being a value type in certain situations. For a mail order company, the address is a value type because it doesn't really matter if the address is shared, who else lives at the address, simply that the package arri开发者_StackOverflow中文版ves at the address.

This makes sense to me until I start thinking about how this would be designed. Given the diagram on page 99, he has it like this:

+------------+
|Customer    |
+------------+
|customerId  |
|name        |
|street      |
|city        |
|state       |
+------------+

This changes to:

+------------+
|Customer    | (entity)
+------------+
|customerId  |
|name        |
|address     |
+------------+

+------------+
|Address     | (value object)
+------------+
|street      |
|city        |
|state       |
+------------+

If these were tables, Address would have its own Id in order to have a relationship with the customer, turning it into an entity.

Is the idea that in a relational database these would stay in the same table, such as in the first example, and that you'd use features of the ORM to abstract address as a value object (such as nHibernate's component features)?

I realize that a couple of pages later he talks about denormalization, I'm just trying to make sure I'm understanding the concept correctly.

When Eric Evans talks about "entities have identity, Value Objects do not", he's not talking about an ID column in the database - he's talking about identity as a concept.

VOs have no conceptual identity. That doesn't mean that they shouldn't have persistence identity. Don't let persistence implementation cloud your understanding of Entities vs VOs.

You can create separate table for address or in same table in Customer

Is the idea that in a relational database these would stay in the same table, such as in the first example, and that you'd use features of the ORM to abstract address as a value object (such as nHibernate's component features)?

Yes, generally, that is the idea.

Alternatively (if your ORM doesn't support Value Objects directly), you can let the VO tables have an ID, but hide that within your domain model.

I personally don't give a damn about having ID on value objects as long as they override equality comparison properly (cause value objects differs by their value not identity).

Mapping value objects to database is technical concern, sometimes (e.g. marking props virtual so ORM could crawl underneath) You just need to sacrifice purity of domain model a bit. Or make Your infrastructure smarter - usage of nhib components or something.

Yes, generally Address would stay in the same table. Address would be mapped something like this:

+-----------------+
|Customer         |
+-----------------+
|customerId       |
|name             |
|address_street   |
|address_city     |
|address_state    |
+-----------------+

If Address was an entity, then it would be in a separate table, as you said. If two of the same Customers linked to the same Address entity, then changing an attribute of that Address would affect both Customers. However, a VO implementation would only affect one or the other.