Comment gérez-vous les "défauts" lorsque vous faites DDD

Question

Je suis intéressé de voir comment les gens traitent les arbres de décision lors de DDD. Par exemple, nous avons besoin que lors de la persistance d'une nouvelle instance de type particulier, certaines associations "par défaut" doivent être construites (pas mal). L'utilisateur est libre de les changer plus tard cependant. Donc, si vous créez une table de décision, comment représentez-vous cela dans votre domaine, ou est-ce le cas? C'est dans le domaine de l'assurance, par exemple, si je choisis une option, tous les avantages, options, etc. "par défaut" associés sont ajoutés à la politique, mais l'utilisateur est libre de la modifier plus tard.

Answer 1

Ceci n'est pas spécifique à DDD en soi, vous devez normalement l'implémenter en utilisant un Factory pour créer votre racine agrégée par défaut. Comme ce comportement est spécifique à l'entreprise et probablement sujet à changement, il est préférable d'externaliser la responsabilité de la création d'objet à l'usine plutôt que de laisser la racine agrégée s'occuper de cela elle-même.

Answer 2

Comme suggéré, utilisez une usine. Pour implémenter la valeur par défaut, utilisez le "special case pattern" tel que décrit par Martin Fowler pour avoir une véritable POO.

Par exemple, si vous avez une politique avec des propriétés prestations et options et ce sont des classes de créer une classe dérivée comme ceci:

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 {}