How are Value Objects stored in the database?

Question

I haven't really seen any examples, but I assume that they are saved inside the containing entity table within the database.

Ie. If I have a Person entity/aggregate root and a corresponding Person table, if it had a Value Object called Address, Address values would be saved inside this Person table!

Does that make sense for a domain where I have other entities such as Companies etc. that have an Address?

(I'm currently writing a project management application and trying to get into DDD)

Graz

Answer 1

It's ok to store Value Objects in a separate table, for the very reasons you've described. However, I think you're misunderstanding Entities vs VOs - it's not a persistence related concern.

Here's an example:

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, and therefore has it's own table

If 2 is true, Address should be a Value Object. It could be stored as a component within the parent Entity's table, or it could have its own table (better database normalisation).

As you can see, how Address is persisted has nothing to do with Entity/VO semantics.

Guglielmo

Could I ask if we stick with the second case where we have VO but we must use separate table because it's a collection of VO. Then the VO (Address) in this example will have a foreign key from the containing entity and will have a key in DB! and this violates that value objects shouldn't have an identity. – Pict

Great, thanks a lot. But if we forget about the ‘DB’ Could i ask what make collection of VO different from entity as implementation (when I design the domain). I have to create a class for this collection which will have a key and the id of the entity.? – Pict

@AnynameDonotcare don't think about entities/values as of tables,.. you can store entity with all value objects as a single document in MongoDB, or as a single node with sub-nodes in XML, or as a JSON object,.. don't couple logic and domain model to technical representation – Pouch

@Vijay Do you have a practical example on how to implement this? Considering a table needs primitives to store finally, considering Address as non table is a bit confusing. Do you mean in repository, we should encode/decode the value objects and persist accordingly? – Regine

@AnynameDonotcare Yeah, but Address will have key in the table, but not in domain logic. I think it's important that they don't have identity inside of domain logic. And as kravemir said, the db is a technical detail. – Planck

I think we can read the OP question in a different way. I think what they mean is: I am using DDD and fully understand the difference between Entities and VO's so my question isn't so much about DDD, that is just the context, my question is, when using DDD how would you deal with the implementation detail of storing VO's in the DB. If using nosql it's easy but they want to use relational which is fine. How do you store and then say hydrate back from the DB VO's in both 1-2-1 case and 1-2-Many case – Propend

Answer 2

Most developers tend to think in the database first before anything else. DDD does not know about how persistence is handled. That's up to the repository to deal with that. You can persist it as an xml, sql, text file, etc etc. Entities/aggregates/value objects are concepts related to the domain.

Explanation by Vijay Patel is perfect.

Erse