aggregate id and aggregate root about m-r

[gregoryyoung]

The aggregate id identifies the aggregate root. All aggregate roots have an id which unique identifies them. This code base uses uuids but {aggregate type}:{incrementing sequence} is just as good.

[coyksdev]

Somehow I understand the theory, however I couldn't implement it in my database design. by aggregate, do you mean it has a separate database table? and the aggregate id is the foreign key inside the events table?

[gregoryyoung]

Ah I see where your problem is coming from. An aggregate is a group of objects. It is better to think about an aggregate as being a document in a document db (and is often implemented as such). In order to access it you need the overall aggregate id and all ids internally need only be unique within the aggregate.

[coyksdev]

Lets say I have an User as Aggregate Root

User {
aggregateId: Guid
username: String
password: String,
roles: [Role]
}

Role: {
name: String
permissions: [Permission]
}

Permission {
name: String
}

[coyksdev]

This is what my events table look like

should I add a aggregate id column?

[gregoryyoung]

I would call it a stream id and map aggregate id to a stream id. I have done this before :) https://github.com/eventstore/eventstore

[gregoryyoung]

Storing a transaction id is a bad idea. Consumers should not be interested in how events are written. If you later wish to have this knowledge you can add a transaction id to the event metadata.

…

On Mon, Mar 5, 2018 at 8:29 AM, campanagerald ***@***.***> wrote: I see. Here is another question, so when i created a user there are two events that happens. UserCreated event and TokenCreated event. Since they are in one transaction, should I design my events table like this? | id | AggregateId | data | createdAt | 1 | wer5hyt6 | { userId: 0, username: "Gerald", password: "xxxxxx"} | | 2 | wer5hyt6 | { tokenId: 0, token: 'cbfg6yth', userId: 0} | — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#27 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXRWmC0tJd-M_kHCDrlBDDBog_Jg7bFks5tbPeFgaJpZM4Sb2dB> .

-- Studying for the Turing test

[coyksdev]

I see. Here is another question, so when i created a user there are two events that happens. UserCreated event and VerificationTokenCreated event. Since they are in one transaction, should I design my events table like this?

[gregoryyoung]

The first. neveventstore made the mistake of taking something similar to the second model. What if I am a subscriber am only interested in VerificationTokenCreated events.

[coyksdev]

thanks greg. i have another question. so to clear my question about the aggregate. should I create a separate table for all aggregates? for example, I have different aggregate roots (User and Role).

| id | AggregateRoot |
| xgftryhf | User |
| yhtyuhu | Role |

[gregoryyoung]

eventstore does not but a table/event type is a valid design and is common in accounting systems. Usually you will have a table called "transactions" where the second column after a unique id is "transaction type" which then specifies the details of the transaction are in a known table.

EventStore does not do this, instead it just records the transaction data in a single conceptual "table"

[coyksdev]

will you provide a concrete example of an events table? here is an article that shows the commonly required fields http://danielwhittaker.me/2014/10/18/6-code-smells-cqrs-events-avoid/. I'm sorry because I have so many questions. hehehe!

[gregoryyoung]

I already have eventstore. That the data is stored directly on disk vs tables makes little difference (aside from performance).

[gregoryyoung]

Further look at Rinat's work and the chapter I wrote about building an eventstore on top of a relational db

[coyksdev]

alright. Thanks for your help. :) We are new to event sourcing and cqrs.

[gregoryyoung]

Good luck 👍 feel free to let me know if you need further help.