ДДД:Может ли объект значения иметь списки внутри себя?

Question

Я не очень хорошо разбираюсь в предметно-ориентированном проектировании и недавно начал создавать предметную модель для проекта.Я до сих пор не определился с ORM (хотя, скорее всего, выберу NHibernate) и в настоящее время пытаюсь убедиться, что мои объекты значений должны быть именно такими.

У меня есть несколько VO, которые почти не ведут себя, кроме как инкапсулировать «подобные» термины, например:

public class Referral {
    public Case Case { get; set; } // this is the a reference to the aggregate root
    public ReferralType ReferralType { get; set; } // this is an enum
    public string ReferralTypeOther { get; set; }
} // etc, etc.

Этот конкретный класс имеет ссылку на «Дело», которое находится на два уровня выше, поэтому, если, скажем, я собираюсь получить доступ к рефералу, я мог бы пойти:case.social.referral (Case, Social и Referral — все это классы, внутри обращения есть одна социальная сеть, а внутри социальной сети — один реферал).Теперь, когда я смотрю на это и печатаю, я не думаю, что мне нужен случай в реферале, поскольку он будет доступен через объект Social, верно?

Теперь я не сомневаюсь, что это должно быть VO, и метод, который я планирую использовать для сохранения этого в базе данных, заключается в том, чтобы либо заставить NHibernate присвоить ему суррогатный идентификатор (который мне до сих пор не совсем ясен в отношении , если бы кто-нибудь мог рассказать об этом подробнее, это помогло бы мне, поскольку я не знаю, требует ли суррогатный идентификатор, чтобы у меня уже был идентификатор в моем VO, или он может работать без него) и/или защищенное свойство Id это не будет отображаться за пределами класса Referral (с единственной целью сохранения в БД).

Теперь перейдем к моему заглавному вопросу:Должен ли ВО иметь внутри коллекцию (в моем случае список)?Я могу думать об этом только как об отношении «один-ко-многим» в базе данных, но, поскольку идентичности нет, мне показалось неадекватным сделать класс сущностью.Ниже приведен код:

public class LivingSituation {
    private IList<AdultAtHome> AdultsAtHome { get; set; }
    public ResidingWith CurrentlyResidingWith { get; set } // this is an enum
} // etc, etc.

В настоящее время у этого класса нет идентификатора, а класс AdultsAtHome имеет только внутренние типы (string, int).Поэтому я не уверен, должен ли это быть объект или он может оставаться как VO, и мне просто нужно настроить мой ORM на использование для этого отношения 1:m, используя свои собственные таблицы и поле частного/защищенного идентификатора, чтобы ORM может сохраняться в БД.

Кроме того, следует ли мне использовать нормализованные таблицы для каждого из моих классов или нет?Я думаю, что мне нужно будет использовать таблицу для каждого класса только тогда, когда есть возможность иметь несколько экземпляров класса, назначенных объекту сущности или значения, и/или существует возможность иметь отношения коллекций 1: m с некоторыми из этих объектов. .У меня нет проблем с использованием одной таблицы для определенных объектов значений, имеющих внутренние типы, но я думаю, что в случае вложенных типов было бы полезно использовать нормализованные таблицы.Есть какие-нибудь предложения по этому поводу?

Извините за столь многословие с множеством вопросов:

1) Нужен ли мне суррогатный идентификатор (скажем, NHibernate) для моих объектов значений?

2) Если № 1 — да, то должно ли это быть частным/защищенным, чтобы мой объект значения «остался» концептуальным объектом значения?

3) Может ли объект значения иметь другие объекты значения (например, список) или он будет представлять собой сущность?(Я думаю, что ответ на этот вопрос отрицательный, но я бы предпочел убедиться, прежде чем двигаться дальше.)

4) Нужна ли мне ссылка на совокупный корень из объекта значения, который находится на несколько уровней ниже совокупного корня?(Я так не думаю, скорее всего это моя оплошность при написании модели, кто-нибудь согласен?)

5) Можно ли использовать нормализованные таблицы для определенных вещей (например, вложенных типов и/или типов с коллекциями в качестве свойств, которым в любом случае потребуются собственные таблицы для отношений 1:m), в то время как ORM выполняет сопоставление для более простых объектов значений в ту же таблицу, которая принадлежит моей сущности?

Еще раз спасибо.

Answer 1

Ознакомьтесь с ответами на связанные вопросы здесь и здесь

---

1) Да - Если вы храните VO в отдельной таблице

2) Если вы можете использовать свойство частного/защищенного идентификатора, тогда отлично.Альтернативно вы можете использовать явные интерфейсы, чтобы «скрыть» свойство ID.

Но, читая ваш вопрос, предполагаете ли вы, что разработчики, которые видят свойство ID, автоматически предполагают, что объект является сущностью?Если да, то им необходимо (пере)обучение.

3) Да, может, но со следующими ограничениями:

• Это должно быть довольно редко
• Он должен ссылаться только на другие ВО.

Также учтите следующее:ВО не должен ошиваться.Было бы легко/эффективно воссоздавать весь VO каждый раз, когда это необходимо?Если нет, сделайте это сущностью.

4) Зависит от того, как вы хотите реализовать свой Агрегатная блокировка.Если вы хотите использовать Решение Айенде, ответ — да.В противном случае вам понадобится механизм для перемещения графа объекта обратно к корню агрегирования.

5) Да.Не забывайте, что DDD Настойчивость (в идеальном мире!).

---

Однако...

Я считаю, что направление должно быть Сущность.Представьте себе эти разговоры:

Разговор 1:

• Том:"Эй Джо!Можете ли вы дать мне направление Дэвида Джонса?»
• Джо:"Который из?"
• Том:«Извините, я имею в виду направление №123»

Разговор 2:

• Том:"Эй Джо!Можете ли вы дать мне направление Дэвида Джонса?»
• Джо:"Который из?"
• Том:«Мне все равно, просто дай мне хоть немного»

Разговор 1 предполагает, что направление – это Сущность, тогда как разговор 2 предполагает, что это озвучка.

Еще кое-что:Делает Referral.ReferralType измениться в течение его жизни (есть еще один намек на то, что это должна быть сущность)?Если оно не делает измените, рассмотрите возможность использования полипоризма и позвольте NH справиться с этим.

Надеюсь, это поможет!