Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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?

like image 415
Landon Poch Avatar asked Oct 13 '12 06:10

Landon Poch


People also ask

Can a value object be an aggregate root?

Thus, the aggregate root must be an entity, not a value object, so that it can be persisted to and from a data store using its ID.

How do you determine the aggregate root?

When choosing an aggregate root you choose between Transactional Consistency and Eventual Consistency. When your business rules allow you would rather favour Eventual Consistency.

What is aggregate and aggregate root?

An AGGREGATE is a cluster of associated objects that we treat as a unit for the purpose of data changes. Each AGGREGATE has a root and a boundary. The boundary defines what is inside the AGGREGATE. The root is a single, specific ENTITY contained in the AGGREGATE.

Can an aggregate root reference another aggregate root?

What you cannot do is reference anything inside the other aggregate root.


1 Answers

While the repository pattern as described in the blue book does emphasize its use being exclusive to aggregates, it does leave room open for exceptions. To quote the book:

Although most queries return an object or a collection of objects, it also fits within the concept to return some types of summary calculations, such as an object count, or a sum of a numerical attribute that was intended by the model to be tallied. (pg. 152)

This states that a repository can be used to return summary information, which is not an aggregate. This idea extends to using a repository to look up value objects, just as your use case requires.

Another thing to consider is the read-model pattern which essentially allows for a query-only type of repository which effectively decouples the behavior-rich domain model from query concerns.

like image 77
eulerfx Avatar answered Nov 10 '22 18:11

eulerfx