Практика DDD: Должен ли я создать репозиторий для объектов значений

Question

Я изо всех сил пытался понять DDD. Вот сценарий, который поражает меня. Скажем, у нас есть Фонд-субъект, который имеет распределение/холдинг ценностей и исторические цены. Что делать, если услуга требует только выделения определенного фонда? Должен ли мы вернуть список объектов распределения или вернуть объект Fund, который содержит список распределений? Если мы прибегнем к первому подходу, нам нужно создать репозиторий распределения. Второй подход кажется немного странным, поскольку объект модифицируется, чтобы возвращать только определенные объекты значения в службу. Не имея большого знания об организации, не должно ли служба иметь все поля фонда, доступные для этого?

Мое описание может быть неточным. Пожалуйста, дайте мне знать, если мне нужно уточнить мой пост.

class Fund 
{ 
    int fundId; 
    List<Allocation> allocations; 
    List<Holding> holdings; 
} 
class Allocation 
{ 
    string type; 
    string percentage; 
} 

Answer 1

Существует несколько вариантов реализаций репозитория, но я бы не отказался возвращать список распределения IF и ТОЛЬКО ЕСЛИ, распределение никогда не управляется самостоятельно.

Другими словами, если вы в какой-то момент захотите получить информацию о распределении, независимо от того, к какому фонду он принадлежит, тогда вам понадобится репозиторий для Allocations, и если вы создадите такой репозиторий, то у вас должен быть такой метод, как getAllocationsbyFundId(int id) или нечто подобное. Если нет смысла смотреть на Allocations самостоятельно, не зная, из какого фонда это, то Allocations действительно являются частью Фонда, и было бы разумно иметь метод в вашем репозитории Фонда, чтобы вернуть Allocations of a определенного Фонда.

Если вы, в конце концов, используете метод GetAllAllocation() в своем репозитории Фонда, вы выскочили из чистого шаблона.

Answer 2

Чтобы ответить на вопрос в названии, вы не должны. Шаблон репозитория работает только в том случае, если элементы в репозитории имеют личность. Если объект имеет идентификатор, то это объект не объект ценности.

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

Это не означает, что версия объекта значения, встроенная в репозиторий, не может иметь идентификатор, но вы не должны препятствовать тому, чтобы проблемы с сохранением изменяли ваш домен.

Основываясь на вашем описании, на самом деле это звучит как Allocation является сущностью, потому что она дифференцируема и, следовательно, имеет личность.

Предполагая, что Allocation является субъектом, вопрос, который я задал бы, должен Allocation быть его собственным агрегатом.

Answer 3

Возможно, я не совсем понимаю ваш домен, поэтому дайте мне знать, если я ошибаюсь. Когда мы принимаем сценарий Order/OrderLine, мы можем моделировать OrderLine как VO (как и ваш Fund/Allocation). Почему мы когда-либо хотели бы запросить сервис, чтобы вернуть только список объектов OrderLine для Order? :)

Однако, если вы действительно нужно сделать это, вы должны быть загрузив экземпляр Fund и используя его, содержащийся Allocations список. Однако запрос вашей модели домена обычно приводит к проблемам (ленивая загрузка, выбор стратегий и отключение от tell-don't-ask). Если вам нужно выполнить запрос, подумайте о создании модели легкого запроса (некоторые называют ее моделью чтения), которая выполняет эту функцию.

Таким образом, я согласен с Mgetz, что у вас должен быть репозиторий VO. Если у вас есть фиксированный список VO, вы можете использовать тип структуры enum. В C# вы можете сделать это с помощью экземпляров класса readonly. Вон Вернон называет это «Стандартные типы» (если используется память). Я не думаю, что у вас есть , что сценарий.