Question

我刚刚开始研究领域驱动设计，并且遇到了一些障碍。

我有很多关系，我试图以DDD的方式设计它。假设我有一个Widget，这是我的聚合。窗口小部件可以具有选项列表，这些选项是描述窗口小部件的值对象。

我认为repo应查询与窗口小部件关联的值对象列表，并在窗口小部件上填充Options属性，而不是在EF中创建多对多关系。

我的域对象看起来像这样：

public class Widget{ 
  public int Id{get;set;}
  public string Name{get;set;}
  public List<Option> Options{get;set;}
  public int DefaultOptionId{get;set;}
}

/* Value Object aka Look Up*/
public class Option{
     public int Id{get;set;}
     public string Name{get;private set;}
}

数据库结构和数据：

  Widget Table Data
       ID: 1 , Name: Widget 1, DefaultOptionId: 2
       ID: 2 , Name: Widget 2, DefaultOptionId: 3

  Option Table
       ID: 1 , Name: Option Name 1
       ID: 2 , Name: Option Name 2
       ID: 3 , Name: Option Name 3
       ID: 4 , Name: Option Name 4

  Relationship Table
      WidgetId: 1 , OptionId: 2
      WidgetId: 1 , OptionId: 3
      WidgetId: 2 , OptionId: 2
      WidgetId: 2 , OptionId: 3
      WidgetId: 2 , OptionId: 4

Answer 1

您提出的解决方案（将选项的水合物列表作为值对象）很好。小部件无法更改Option值对象，因此共享引用对小部件无影响。

重命名选项不会改变此解决方案，因为小部件只会在下次由回购再次水合时选取重命名的选项。

'value object'的概念与使用上下文有关：在widget上下文中，Option是不可变的。在某些其他上下文中（如“选项”），它可能是可变的（因此您可以重命名选项）。

另见https://martinfowler.com/bliki/ValueObject.html

如何为可以属于多个聚合的ValueObject建模

1 个答案: