78

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)

kitsune
  • 11,516
  • 13
  • 57
  • 78

2 Answers2

154

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.

danronmoon
  • 3,814
  • 5
  • 34
  • 56
Vijay Patel
  • 17,094
  • 6
  • 31
  • 35
  • 2
    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. – Anyname Donotcare Aug 31 '18 at 18:26
  • 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.? – Anyname Donotcare Sep 01 '18 at 08:37
  • 1
    @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 – kravemir Oct 05 '19 at 05:57
  • @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? – Ayyappa Sep 17 '21 at 06:48
  • @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. – scovic Oct 16 '21 at 13:16
26

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.

Pepito Fernandez
  • 2,352
  • 6
  • 32
  • 47