Как построить сложный объект-ценность?

Я только начал изучать DDD. Так что извиняюсь за глупый вопрос...

Итак, у меня есть объект Post. Это выглядит хорошо. Но он должен иметь tags. В коде это выглядит так (рубиновый код):

class Post
  attr_reader :tags
  attr_reader :title
  attr_reader :text
  # ...
end

class Tag
  attr_reader :name
  attr_reader :description
  # ...
end

Теги не имеют смысла как сущности. Мне не нужен сам tag. Но как мне реализовать репозиторий для сообщений? Я нашел 2 варианта:

1. Создавайте теги в одном репозитории. Нравится:

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

Но выглядит некрасиво. Не могу четко сказать, почему.

2. Создайте отдельный репозиторий для тегов.

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

Выглядит лучше. Но можно ли сделать отдельный репозиторий для объектов-значений?

Каков правильный путь согласно DDD?

UPD: С другой стороны, мне нужно получить все доступные теги. И мне никогда не приходится менять теги с сообщениями. И имя тега выглядит как личность. Может я в корне не прав? Может быть, тег - это сущность?

UPD2:

Эта проблема показывает мне, что мои дизайнерские навыки очень плохи. Из-за этого в моем вопросе два. Они есть:

  1. Каков правильный способ создания объекта значения внутри репозитория сущностей.
  2. Как увидеть разницу между значением и сущностью в моей задаче. Ведь вроде ясно. Согласно заданным условиям, тег является значением. И это нормально, что он собран репозиторием Post.

Но это состояние является результатом плохого анализа. Если бы я мог смотреть шире, я бы увидел, что у тега есть свой жизненный цикл. Хотя в контексте публикации теги неизменяемы.


person anoam    schedule 14.04.2017    source источник
comment
Спросите себя, если тег назывался ddd, а затем вы решили переименовать его в domain-driven-design для будущего использования, должен ли он отражать ранее отмеченные сообщения или нет? Если нет, то это значение, в противном случае это, скорее всего, неизменяемая сущность в контексте постов, но изменяемая сущность в контексте управления тегами.   -  person plalx    schedule 15.04.2017
comment
@plalx, ​​не могли бы вы переместить свой комментарий в ответы? Это полезно, и я хочу проголосовать за это.   -  person anoam    schedule 17.04.2017


Ответы (1)


Тег, скорее всего, является обычным объектом-значением в вашем домене. Тег мог бы быть сущностью, если бы у него был свой жизненный цикл. Честно говоря, я не думаю, что это так в вашем домене, так как вы можете заменить каждый тег другой копией с теми же свойствами.

Вы можете добавить методы для запроса тегов в репозиторий вашего домена. Это не нарушение сводных правил DDD. Агрегаты действительно связаны с согласованностью — ваши репозитории не должны возвращать части вашего агрегата, если вы можете изменить их вне контекста агрегата. Однако вы можете явно возвращать объекты значений ваших агрегатов только для целей чтения (например, собирать все теги всех сообщений в выбранном диапазоне дат). Кроме того, методы запроса должны быть размещены внутри репозитория для эффективности. При этом в вашем случае, вероятно, лучшим решением является использование отдельной модели чтения (например, с использованием nosql db) в соответствии с принципами CQRS. Таким образом, у вас есть модель, явно настроенная в соответствии с потребностями вашего запроса, поэтому она может быть очень эффективной.

person Mike Wojtyna    schedule 15.04.2017