始终有效的实体

时间:2014-07-03 15:01:27

标签: oop domain-driven-design invariants

我有兴趣了解"始终有效"的支持者。实体方法(以后称为isValid方法)建议使用集合对对象建模。我非常喜欢这种方法背后的想法,但是我很难实现它,因为我的对象变得更复杂了。我想知道,我是否需要强制用户只使用一种更新方法,并指定所有字段?

例如:

public Meeting
{
   public string Name {get; protected set;}        -- must have
   public DateTime Time {get; protected set;}      -- must have
   public IWine Wine {get; protected set;}         -- optional
   public string Notneeded2 {get; protected set;}  -- optional
   public string Notneeded3 {get; protected set;}  -- optional
   public string Notneeded4 {get; protected set;}  -- optional
   public string Notneeded5 {get; protected set;}  -- optional
   public string Notneeded6 {get; protected set;}  -- optional

   public IUser Chair {get; protected set;}         --must have 
   public List<IUsers> Users {get; protected set;}  --must have
   public bool isBoardRelated {get; protected set;}  --must have
   public List<IBoardUsers> {get; protected set;}   -- if isBoardRelated, then must have

   private void CheckInvariants()
   {
       if (blah == null &&....etc)
       {
             throw new ModelInvariantCheckException("Catch me and cry");
        }
    }

}

那么,下面是否应该只为一个构造函数和一个指定了所有字段的更新方法提供给用户?或者应该使用多个构造函数?是否允许某些属性(选项)让公共设置者使事情不一致?

或者人们更喜欢使用必须稍后调用的isValid方法?

我必须说,我的首选是进行不变检查,因为它感觉更安全,但是必须将每个属性添加到构造函数和更新方法,这使得在层之间调用时速度变得更慢,甚至对象设置。由始终有效的类组成的集合会加剧这种情况。

1 个答案:

答案 0 :(得分:3)

练习域驱动设计时,您希望避免使用大型Update方法。更新方法不捕获域的语言 - 它们将数据库语言引入您的域。尝试使语言显式化,您将能够提取改变实体状态的值对象,不变量和意图揭示方法。

也许你可以找到一些灵感here