Как вы справляетесь с «значениями по умолчанию» при выполнении DDD

Question

Мне интересно посмотреть, как люди справляются с деревьями решений при выполнении DDD. Например, у нас есть требование, что при сохранении нового экземпляра определенного типа должны быть построены некоторые ассоциации «по умолчанию» (довольно много). Пользователь может изменить их позже, хотя. Итак, если кто-то создает таблицу решений, как вы это представляете в своем домене или нет? Это относится к области страхования, поэтому, например, если я выберу один вариант, все связанные с ним «преимущества по умолчанию», опции и т. Д. Будут добавлены в полис, но пользователь сможет изменить его позже.

Answer 1

Как предложено использовать завод. Для реализации значения по умолчанию используйте « шаблон специального случая », как было описано Мартином Фаулером, для получения реального ООП.

Например, если у вас есть свойства Policy with Benefit и Options, и они являются классами, создайте производный класс, подобный этому:

class Policy
{
Benefit Benefit {get;set;}
IList<Option> Options {get;set;}

//Factory
public static Policy CreateDefaultPolicy()
{
  var retVal = new Policy();
  retVal.Benefit = new DefaultBenefit();
  retVal.Options =new List<Options> ();
  retVal.Options.Add(DefaultLifeOption);
  retVal.Options.Add(DefaultCarOption);
  retun retVal;
}
}

class Benefit {}
class DefaultBenefit: Benefit {}

class Option{}
class DefaultLifeOption {}
class DefaultCarOption {}

Answer 2

Это не относится к DDD как таковому, вы обычно реализуете это, используя Factory для создания вашего сводного корня по умолчанию. Поскольку это поведение специфично для бизнеса и, вероятно, подвержено изменениям, лучше передать ответственность за создание объекта на фабрику, чем позволить самому объединенному корню справиться с этим самим.