0

In Domain Driven Design (DDD), an Entity always has its own unique identity.

In my reading on DDD I have seen statements and examples that seem to mix the concepts of "unique identity" between Entities and Aggregate Roots. Depending on the example, they can imply that:

  • I only need one of the interfaces below.

or

  • I need both.

I would like to know which approach is "correct" as far as "Eric Evans type DDD" is concerned.

For example, let's say your Entities implement this interface and return a GUID when this method is called:

public interface IEntity
{
   object IdThatIsUniqueForThisEntityObject { get; }
}

Do you need the one below too or not?

public interface IAggregateRoot
{
   object IdThatIsUniqueForThisAggregateRootObject { get; }
}

Does the Aggregate Root need to implement an interface like the one above so that it can represent its own unique ID (IdThatIsUniqueForThisAggregateRootObject) that is separate and different from its root Entity's ID (IdThatIsUniqueForThisEntityObject)?

Or should the Aggregate Root just use the root Entity's (IdThatIsUniqueForThisEntityObject) to represent the Unique ID of the Aggregate Root?

Kerry
  • 341
  • 2
  • 11

1 Answers1

3

You only need the EntityId. There is no additional Aggregate Root Identity that is created. An aggregate root is an aggregate that is used to control access and organize objects as a single unit of database work. The aggregate does not confer any sort of "new" or additional identity for an object.

An entity always has it's unique entity identity and that should be sufficient. By definition, an operation that retrieves an entity which is an aggregate root also retrieves the aggregate in doing so. There is no concept of an entity which is sometimes just the standalone entity, and other times the aggregate root. So there is also no need for a concept of "Aggregate Root Identity" at all.

Sisyphus
  • 4,181
  • 1
  • 22
  • 15
  • Thank you. Then is it correct to say that, “All entities and value objects in the domain context MUST be contained in a boundary called an Aggregate and the ONLY way to get access to any entity or value object in the domain model is THROUGH an Aggregate Root. An entity and/or value object CANNOT (should not) ever be accessible outside of an Aggregate boundary.”? – Kerry May 22 '11 at 23:20
  • No. Value objects (as long as they are immutable) can come from anywhere, and be used anywhere. Aggregate rules do not apply to value objects. Other than that, the statement is essentially true. Standalone objects are effectively aggregates of one. So yes, all entity objects should either be accessible as an aggregate root (defining standalone objects as aggregate roots) or by traversal from the aggregate root which the entity belongs to. The one exception is in factories. Assembling a new aggregate requires whatever. Access rules apply to the final, complete aggregate. – Sisyphus May 22 '11 at 23:55