How value objects are saved and loaded?

Question

Since there aren no respositories for value objects. How can I load all value objects?

Suppose we are modeling a blog application and we have this classes:

• Post (Entity)
• Comment (Value object)
• Tag (Value object)
• PostsRespository (Respository)

I Know that when I save a new post, its tags are saved with it in the same table. But how could I load all tags of all posts. Should PostsRespository have a method to load all tags? I usually do it, but I want to know others opinions

Godesberg

Answer 1

I'm looking for a better solution for this question and I found this post:

http://gojko.net/2009/09/30/ddd-and-relational-databases-the-value-object-dilemma/

This post explain very well why there is a lot of confusion with value objects and databases. Here you are phrase which liked me too much:

• "Persistence is not an excuse to turn everything to entities."

Gojko Adzic, give us three alternatives to save our value objects.

Godesberg

Relational databases and ORMs often trick us into creating accidental entities jefclaes.be/2013/05/accidental-entities-you-dont-need-that.html – Coati

@Godesberg If I save value object in a text column (option 3) , how should I do to perform an atomic update on value object? – Delamare

@Godesberg Such a nice article that help me a lot. Thanks – Necessity

Answer 2

I am currently working through a similar example. Once you need to uniquely refer to tags they are no long simple value objects and may continue to grow in complexity. I decided to make them their own entities and create a separate repository to retrieve them. In most scenarios they are loaded or saved with the post but when they are required alone the other repository is used.

I hope this helps.

EDIT: In part thanks to this post I decided to restructure my application slightly. You are right that I probably was incorrectly making tags an entity. I have since changed my application so that tags are just strings and the post repository handles all the storage requirements around tags. For operations that need posts the tags are loaded with them. For any operation that just requires tags or lists of tags the repository has methods for that.

Janson

Thanks for the answer. So you have an TagsRepository. Do you have a Tags table in database too? – Godesberg

I actually have not decided on the database yet. I probably will not have a separate database and am strongly considering an object or document database solution like mongo or couch. – Janson

Answer 3

Here is my take in how I might solve this type of problem in the way that I'm currently practicing DDD.

If you are editing something that requires tags to be added and removed from such as a Post then tags may be entities but perhaps they could be value objects and are loaded and saved along with the post either way. I personally tend to favor value objects unless the object needs to be modified but I do realize that there is a difference between entity object modeled as read only "snapshots" and actual value objects that lack identity. The tricky part is that perhaps sometimes what you would normally think of as a key could be part of a value object as long as it is not used as identity in that context and I think tags fall into this category.

If you are editing the tags themselves then it is probably a separate bounded context or at least a separate aggregate in which tags are themselves are the aggregate root and persisted through a repository. Note that the entity class that represents tags in this context doesn't have to be the same entity class for tags used in Post aggregate.

If your listing available tags on the display for read only purposes such as to provide a selection list, then that is probably a list of value objects. These value objects can but don't have to be in the Domain Model since they are mainly about supporting the UI and not about the actual domain.

Please chime in if anybody has any thoughts on why my take on this might be wrong but this is the way I've been doing it.

Papotto