How to model ValueObject that can belong to multiple aggregates

Question

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

That was going to be my follow up question :) How do people typically handle this type of situation? A list of options can be modified via an administration area, but if an option is associated to a Widget i don't believe a user should be able to, because then all the widgets that have this option would change. This seems overly complicated, but must be a common design challenge. — GregL, Jan 13 '17 at 14:40
It is for you to decide, in *your* domain ;) The rename case will tell you a lot, because it shows if a widget option is frozen at the time it is added (maybe more Value Object-like) or if the "master" Option can evolve and must always stay synchronized everywhere (more likely an Entity) — guillaume31, Jan 13 '17 at 16:39
Ya, I think the updating/deleting referenced options is a business rule, that I need to workout with the client. I am still wondering how DDD designers typically deal with lookups that can be related multiple aggregates. — GregL, Jan 13 '17 at 20:43
Most of the time, as (pseudo) Aggregate Roots - see http://stackoverflow.com/questions/12870650/should-lookup-values-be-modeled-as-aggregate-roots CQRS comes in handy then if you often want the widget together with its options. But you shouldn't miss an opportunity to make them Value Objects if the domain lends itself to it. — guillaume31, Jan 14 '17 at 10:10

score 1 · Accepted Answer · answered Jan 18 '17 at 08:16

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

Thanks! great answer! Thanks for the link, I think I will be re-reading Martin's site a lot. As I familiarize myself with DDD! — GregL, Jan 19 '17 at 14:47

How to model ValueObject that can belong to multiple aggregates

1 Answers1