How do you deal with "defaults" when doing DDD

Question

I am interested to see how people deal with decision trees when doing DDD. For example we have a requirement that when persisting new instance of particular type, some "default" associations have to be built (quite a few). User is free to change them later on though. So if one creates a decision table, how do you represent this in you domain, or do you? This is in insurance domain, so for example, if I choose one option then all related "default" benefits, options etc, get added to the policy, but user is then free to change it later on.

Answer 1

This is not specific to DDD per se, you would normally implement this using a Factory to create your default aggregate root. As this behavior is business specific and probably subject to change, externalizing the responsibility for object creation to the factory is better than letting the aggregate root deal with this itself.

Answer 2

As suggested use a factory. To implement the default use the "special case pattern" as described by Martin Fowler to have real OOP.

For example if you have a Policy with Benefit and Options properties and they are classes create a derived class like this:

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