domain driven design - How to build complex value-object? -

i have started learn ddd. apologise silly question...

so have post entity. looks fine. should have tags. in code looks (ruby code):

class post   attr_reader :tags   attr_reader :title   attr_reader :text   # ... end  class tag   attr_reader :name   attr_reader :description   # ... end 

tags aren't make sense entity. don't need tag itself. how should implement repository post? have found 2 variants:

1. build tags in same repository. this:

# postrepository def find(id)   # getting post data storage here   # getting tags data   post.new(title, text, tags_data.map { |tag_data| tag.new(tag_data[:name], tag_data[:description])) end 

but looks ugly. can't why.

2. make separate repository tags.

# postrepository def find(id)   # getting post data storage here   post.new(title, text, tag_repository.find(tag_ids)) # or tag_names or tag_something end 

looks better. fine make separate repository value-objects?

what right way according ddd?

upd: in other hand, have available tags. , never have change tag posts. , tags' name looks identity. maybe i'm fundamentally wrong? maybe tag entity?

upd2:

this problem shows me design skill poor. because of it, there 2 question in one. are:

1. what right way build value object inside entities' repository.
2. how see difference between value , entity in problem. after looks clear. according specified conditions, tag value. , it's ok it's builded post's repository.

but conditions result of poor analize. if wider, see tag has it's own life cycle. though, in context of post, tags immutable.

tag regular value object in domain. tag entity, if had own lifecycle. frankly, don't think that's case in domain, can replace each tag copy same properties.

you can add methods query tags domain repository. it's not violation of ddd aggregate rules. aggregates consistency - repositories should not return parts of aggregate if can modify them outside of aggregate context. however, can explicitly return value objects of aggregates read purposes (e.g. collecting tags of posts within selected date range). besides that, query methods should placed inside repository sake of efficiency. being said, in case best solution use separate read model (using e.g. nosql db) following cqrs principles. way have model explicitly adjusted query needs, can efficient.