AggregateRootId vs EntityId for the AggregateRoot Entity.

[Fredrik Hörte]

Hi, I have quite recently started a project using CQRS and I have used an example by Erik Rozendaal (https://github.com/erikrozendaal/cqrs-lottery) as my CQRS-seed.

I have an AR called BankAccount. The serialized event looks like below. Note, that since the AR also are an Entity it has an entityId. In this implementation the aggregateRootId and entityId are the same for the AR. Is it always like this or is it common to have one aggregateRootId like a GUID and another entityId (e.g. incrementing id) even for the AR? I'm thinking that if I need to refactor later and move the AR to another level e.g. want to have a Cutomer as the AR instead how would I go ahead and do that if the BankAccount has the same entityId as the aggregateRootId?

{

  "type": "BankAccountCreated",

  "event": {

    "accountNumber": "0000 123456789",

    "aggregateRoot": {

      "id": "0217b16f-24d3-3952-b626-2b21b6b1caf0",

      "version": 0

    },

    "entityId": "0217b16f-24d3-3952-b626-2b21b6b1caf0"

  }

}

[Greg Young]

An aggregate is a special type of entity it being it has a globally
unique identifier. One thing that often gets left out with entities is
that they only need an id unique within their aggregate.

Cheers,

Greg

> --
> You received this message because you are subscribed to the Google Groups
> "DDD/CQRS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dddcqrs+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Studying for the Turing test

[Fredrik Hörte]

Would it be bad/unconvetional to have one id for the aggregate and another for the entity that acts as the aggregate root?

In this case BankAccount act as the aggregateRoot. AggregateRootId is not the same as the entityId.

{

  "type": "BankAccountCreated",

  "event": {

    "accountNumber": "0000 123456789",

    "aggregateRoot": {

      "id": "0217b16f-24d3-3952-b626-2b21b6b1caf0",

      "version": 0

    },

    "entityId": "some-id"

  }

}

[Fredrik Hörte]

To clarify. What I am trying to figure out is weather or not it is common to have a separate AggregateId that all entities refer to (even the Entity that acts as AggregateRoot) instead of having Entities refer to the EntityId of the AggregateRoot.

Alternative A:

BankAccount (AR)

 id: 1

BankTransaction

 id: 2

 aggregateRootId: 1

Alternative B

BankAccount 

  id: 1

  aggregateId: 1234

  isAggregateRoot: true

BankTransaction

  id: 2  

  aggregateId: 1234

[Nils Kilden-Pedersen]

On Wed, Jul 8, 2015 at 6:21 AM, Fredrik Hörte <fredri...@gmail.com> wrote:

To clarify. What I am trying to figure out is weather or not it is common to have a separate AggregateId that all entities refer to (even the Entity that acts as AggregateRoot) instead of having Entities refer to the EntityId of the AggregateRoot.

I don't think that's common, at least I haven't seen that done. Typically the AR (which is an Entity) will have a different id type (globally unique) than AR member entities (locally unique).

The cardinality between AR and Aggregate entity is 1-to-1, so it would me redundant and unnecessary to have an additional id.

 

--

[Fredrik Hörte]

Thank you Nils for sorting this out. Though a follow-up question; is it common to have a special Entity that is just a holder for entities e.g. in my example above BankTransaction is a member of BankAccount, whereas BankAccount is the AR. Would it make sense to have an AR that is just a "place holder" and have both BankAccount and BankTransaction as nested members in that SomeAggregateRootClass?

[Nils Kilden-Pedersen]

On Wed, Jul 8, 2015 at 1:16 PM, Fredrik Hörte <fredri...@gmail.com> wrote:

Thank you Nils for sorting this out. Though a follow-up question; is it common to have a special Entity that is just a holder for entities e.g. in my example above BankTransaction is a member of BankAccount, whereas BankAccount is the AR. Would it make sense to have an AR that is just a "place holder" and have both BankAccount and BankTransaction as nested members in that SomeAggregateRootClass?

I can't tell you what's common, as I wouldn't know, but I don't think it makes sense to separate the two. The fact that you don't even know what to call it (SomeAggregateRootClass), should tell you that it's probably not what you want.

[Fredrik Hörte]

Good point! Thx