Question

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 arrives 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.

Answer 1

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.