Repositories and Roots of aggregates

2
votes

I'm reading a book by Eric Evans DDD. And I found a contradiction.

Chapter books about aggregates:

Choose one ENTITY to be the root of each AGGREGATE, and control all access to the objects inside the boundary through the root.

Chapter books about repositories:

A subset of persistent objects must be globally accessible through a search based on object attributes. Such access is needed for the roots of AGGREGATES that are not convenient to reach by traversal. They are usually ENTITIES, sometimes VALUE OBJECTS with complex internal structure, and sometimes enumerated VALUES. Providing access to other objects muddies important distinctions.

Provide REPOSITORIES only for AGGREGATE roots that actually need direct access.

It can be concluded that the root of the aggregate can be:

  • entity
  • value object
  • enumerated values

Correctly I understood everything?

Or may be right:

Provide REPOSITORIES only for

  • aggregate roots
  • value objects
  • enumerated values ?

And what is enumerated values(which needs its own repository!)?

1
domain-driven-designddd-repositories
the root of an aggregate is always an entity. also, you only provide repositories for aggregate roots. value objects and enums do not have a life cycle and need to be located by a global unique identity. - Marco
But for global access value objects and enums require their own repositories. Isn't it? - stalxed
value objects are identified by their attributes not a global id. depending upon the bounded context a value object may be an aggregate in another BC. also, vaughn vernon calls enums/lookup data Standard Types and can simply be loaded from the data source. - Marco

1 Answers

0
votes

Per @Marco's comment above, the root of an aggregate can only be an entity (i.e. something with an ID property). An example of this would be an Order object. No matter how many attributes you change on an Order its quality is determined by its Id property and nothing else.

A value object (often implemented as a struct in many languages) does not have an ID. A common example of this would be a Money value object with a Dollars property and Cents property. Because it has no ID, the concept of querying it by ID does not apply, and thus the concept of a repository does not apply. An aggregate could have a value object as a property, though (e.g. the Total property on an Order aggregate).

An enumerated type is just a list of name/value pairs. It uses the enum keyword in several languages. Again, there's no ID for the enum nor any of its members, so the concept of a repository does not apply. The concept of an enum is useful in DDD because it helps express the domain model better than, say, magic numbers e.g. order.Status = OrderStatus.Submitted vs order.Status = 1.