Aggregate Root Id generation best practices
1,620 views
Skip to first unread message
bunk
Dec 21, 2010, 4:11:58 PM12/21/10
to DDD/CQRS
Are there any best practices for handling aggregate root id's? My
current implementation is generating unique GUID's at the client and
sending them along with the commands; however, we have recently come
up against a case where we need to generate a non-globally unique
identifier for an aggregate root. In this case it seems like a domain
service should handle creating this Id, but if we're using
asynchronous command dispatching the client will not know what the Id
is until it propagates to the read database. Here's the domain
description:
- Criminal AR
(globally unique representation of a person)
- Booking AR
(handles intake for a Criminal[AR]--moment-interval, I think)
- Jail AR
(handles generating an id for the booking that is unique within the
jail)
Jail is a part of the Housing bounded context, where Booking and
Criminal are a part of the Booking BC. I'm anticipating that the
Booking will require a globally unique GUID key as well as this unique
Jail identifier as we are using event sourcing on the write side.
current implementation is generating unique GUID's at the client and
sending them along with the commands; however, we have recently come
up against a case where we need to generate a non-globally unique
identifier for an aggregate root. In this case it seems like a domain
service should handle creating this Id, but if we're using
asynchronous command dispatching the client will not know what the Id
is until it propagates to the read database. Here's the domain
description:
- Criminal AR
(globally unique representation of a person)
- Booking AR
(handles intake for a Criminal[AR]--moment-interval, I think)
- Jail AR
(handles generating an id for the booking that is unique within the
jail)
Jail is a part of the Housing bounded context, where Booking and
Criminal are a part of the Booking BC. I'm anticipating that the
Booking will require a globally unique GUID key as well as this unique
Jail identifier as we are using event sourcing on the write side.
@seagile
Dec 21, 2010, 4:24:24 PM12/21/10
to DDD/CQRS
What's the type of that Booking ID and why can't you generate it on
the client (do you know the jail id at the client side)? As for
clients tracking messageflow, correlation identifiers work miracles.
the client (do you know the jail id at the client side)? As for
clients tracking messageflow, correlation identifiers work miracles.
bunk
Dec 21, 2010, 4:50:11 PM12/21/10
to DDD/CQRS
It's a simple sequential numeric Id. I'm thinking we could generate
the Id based off of the read model and possibly issue a
SetNextIdentifier command to the Jail AR in the domain to handle
consistency?
the Id based off of the read model and possibly issue a
SetNextIdentifier command to the Jail AR in the domain to handle
consistency?
@seagile
Dec 21, 2010, 5:42:12 PM12/21/10
to DDD/CQRS
How many bookings happen at the same time instance? How does the
business use this identifier? Could you classify the Booking ID as a
surrogate id? Why not let the client specify a guid for the booking
and generate an additional sequence id? You could also generate an
identifier after the Booking, using a specific Command maybe?
business use this identifier? Could you classify the Booking ID as a
surrogate id? Why not let the client specify a guid for the booking
and generate an additional sequence id? You could also generate an
identifier after the Booking, using a specific Command maybe?
Scott Reynolds
Dec 22, 2010, 2:50:53 AM12/22/10
to ddd...@googlegroups.com
This is exactly what we do. our command handler gets a sequential from our id generator. All domain interactions however continue to use guids but the client has a nice domain controlled id to look at.
bunk
Dec 22, 2010, 9:59:47 AM12/22/10
to DDD/CQRS
I hadn't thought of that solution. Would the id generator be sent a
command to generate an id -> a BookingIdGeneratedEvent getting
published for the booking guid -> read store updating the already
created Booking record? I like that solution.
The requirement on the business end is that an id is used to track the
inmate within a facility (jail or prison) via arm band. They also
reference this number throughout the facility and print them on
clothing, etc. A guid is not something they want to deal with in that
way and systems they are used to using use simple sequential integer
identifiers.
On Dec 22, 1:50 am, Scott Reynolds <sco...@reynoldsphotography.com>
wrote:
command to generate an id -> a BookingIdGeneratedEvent getting
published for the booking guid -> read store updating the already
created Booking record? I like that solution.
The requirement on the business end is that an id is used to track the
inmate within a facility (jail or prison) via arm band. They also
reference this number throughout the facility and print them on
clothing, etc. A guid is not something they want to deal with in that
way and systems they are used to using use simple sequential integer
identifiers.
On Dec 22, 1:50 am, Scott Reynolds <sco...@reynoldsphotography.com>
wrote:
> This is exactly what we do. our command handler gets a sequential from our
> id generator. All domain interactions however continue to use guids but the
> client has a nice domain controlled id to look at.
> id generator. All domain interactions however continue to use guids but the
> client has a nice domain controlled id to look at.
Scott Reynolds
Dec 22, 2010, 10:31:28 AM12/22/10
to ddd...@googlegroups.com
In my case we just do the is generation is the 'create' command handler.
Reply all
Reply to author
Forward
0 new messages