Reputation: 77
I am just starting to study Domain Driven Design and have run into a bit of a road block.
I have a many to many relationship I'm trying to design it in a DDD way. Say I have a Widget which is my aggregate. The widget can have a list of options which are value objects that describe the widget.
I am thinking the repo should query for the list of value objects associated to the widget and populate the Options property on the widget instead of creating a many to many relationship in EF.
My Domain Object Look like this:
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;}
}
DB structure and data:
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
Upvotes: 2
Views: 823
Reputation: 61242
Your proposed solution (repo hydrate list of options as value objects) is fine. The Option value-objects cannot be altered by the widget, so shared references are of no consequence to the widget.
Renaming an Option does not change this solution, as the widget would just pick up the renamed Option the next time it is rehydrated by the repo.
The notion of 'value object' is relative to the context of use: in the widget context, Option is immutable. In some other context (like 'Option') it may be mutable (so you can rename an Option).
See also https://martinfowler.com/bliki/ValueObject.html
Upvotes: 1