DDD: Help me better understand Value Objects and Objects

Question

There are several questions about this, and reading them does not help me. In Eric Evans' DDD, he uses an example address that is a value type in certain situations. For a mailing company, an address is a type of value, since it doesn’t really matter if the common address is, who else lives at the address, just for the packet to arrive at the address.

It makes sense to me until I start thinking about how it will be created. Given the chart on page 99, it has the following:

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

This changes to:

 +------------+ |Customer | (entity) +------------+ |customerId | |name | |address | +------------+ +------------+ |Address | (value object) +------------+ |street | |city | |state | +------------+ 

If these were tables, the address would have its own Identifier in order to have a relationship with the client, turning it into an entity.

Is the idea that in a relational database they will remain in the same table, for example, in the first example, and that you should use the ORM functions for the abstract address as an object of value (for example, the function of the nHibernate component)

I understand that a few pages later he talks about denormalization, I'm just trying to make sure that I understand the concept correctly.

Answer 1

Is the idea that in the relational database they will remain in the same table as in the first example, and that you will use the ORM functions for the abstract address as an object of value (for example, the nHibernate component features)?

Yes, in general, this is the idea.

Alternatively (if ORM does not support Value objects directly), you can allow VO tables to have an identifier, but hide it in your domain model.

Answer 2

When Eric Evans says that “entities have identity, Value objects do not matter,” he does not talk about the identifier column in the database — he talks about identity as a concept.

VOs have no conceptual identity. This does not mean that they should not have constancy. Do not let persistence implementations have your understanding of entities against VOs.

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

Answer 3

I personally don’t give a damn about the presence of an identifier on value objects if they correctly redefine equality comparison (the reason that value objects differ in their value, and not in the identifier).

Comparing value objects with a database is of technical interest, sometimes (for example, marking virtual details so that ORM can scan from below). You just need to sacrifice a little clean model domain. Or make your infrastructure smarter - using nhib components or something.

Answer 4

Yes, usually the address will remain in one table. The address will be displayed as follows:

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

If the Address was an entity, then it will be in a separate table, as you said. If two of the same Clients are associated with the same Address object, then changing the attribute of this address will affect both Clients. However, the implementation of VO will only affect one or the other.