DDD: Может ли объект Value иметь списки внутри них? - PullRequest
6 голосов
/ 30 ноября 2009

Я не очень разбираюсь в проектировании, управляемом доменом, и недавно я начал создавать модель домена для проекта. Я до сих пор не определился с 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», которая находится на два уровня выше, поэтому, если я скажу, что собирался получить доступ к Рефералу, я мог бы пойти: case.social.referral (Case, Social и Referral - все классы, один социальный пакет внутри дела, и в социальном списке есть один реферал). Теперь, когда я смотрю на него, когда я его набираю, я не думаю, что мне нужен Кейс в Реферале, так как он будет доступен через социальную сущность, правильно?

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

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

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

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

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

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

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

2) Если # 1 - да, то нужно ли это быть закрытым / защищенным, чтобы мой объект значения "оставался" объектом значения в понятии?

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

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

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

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

1 Ответ

9 голосов
/ 30 ноября 2009

Посмотрите ответы на похожие вопросы здесь и здесь


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

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

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

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

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

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

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

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


Однако ...

Я считаю, что Реферал должен быть Entity . Представьте себе эти разговоры:

Разговор 1:

  • Том: «Привет, Джо! Можешь дать мне направление Дэвида Джона?»
  • Джо. "Какой?"
  • Том: «Извините, я имею в виду Реферал № 123»

Разговор 2:

  • Том: «Привет, Джо! Можешь дать мне направление Дэвида Джона?»
  • Джо: "Какой?"
  • Том: «Мне все равно - просто дай мне что-нибудь»

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

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

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

...