Search code examples
domain-driven-designlookup-tablesaggregateroot

Should lookup values be modeled as aggregate roots?


As part of my domain model, lets say I have a WorkItem object. The WorkItem object has several relationships to lookup values such as:

WorkItemType:

  • UserStory
  • Bug
  • Enhancement

Priority:

  • High
  • Medium
  • Low

And there could possibly be more, such as Status, Severity, etc...

DDD states that if something exists within an aggregate root that you shouldn't attempt to access it outside of the aggregate root. So if I want to be able to add new WorkItemTypes like Task, or new Priorities like Critical, do those lookup values need to be aggregate roots with their own repositories? This seems a little overkill especially if they are only a key value pair. How should I allow a user to modify these values and still comply with the aggregate root encapsulation rule?


Solution

  • Landon, I think that the only way is to make those value pairs aggregate roots. I know that is might look overkill, but that's DDD braking things into small components.

    The reasons why I think using a repository is the right way are:

    • A user needs to be able to add those value pairs independently of a Work Item.
    • The value pairs don't have a local, unique identity

    Remember that DDD is just a set of guidelines, not hard truths. If you think that this is overkill, you might want to create a lookup that returns the pairs as value objects. This might work out specially if you don't have a feature to add value pairs in the application, but rather through the database.

    As a side note, good question! There are quite a few blog posts about this situations... But not all agree on the best way to do this.