If an Entity becomes the root of an Aggregate, does the Aggregate Root use the existing ID of the root Entity or does the AR create its own ID?

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开发者_如何学JAVA 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?

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.