Aggregate/Entity ids handling.

[stefanondisponibile]

Hello!
In Chapter 9 we need a Temporary Ugly Hack: The Message Bus Has to Return Results.
That's fine, since that's "solved" by CQRS in Chapter 12. However, what concerns me is: where should ids be handled?. Generically at a "system" level or at "Domain Model" level?

In one of the examples, more or less, this is what is done:

order_id = random_order_id()
api_client.post_to_allocate(order_id, sku, qty=3)

And this is kinda fine, since we would probably be getting the order_id from a view with CQRS. But how about creation of new objects? Where should the "id logic" be put?

# Creating new "Thing"
new_thing_id = 123  # the logic is either here or "lost", unless we return from the message bus 🤔
api_client.post_to_create_new_thing(new_thing_id)

This is somehow related to #299 too.

[hjwp]

one solution is to choose the unique ids yourself, rather than letting the database do it for you. there's an example in one of @bobthemighty's original blog posts: https://www.cosmicpython.com/blog/2017-09-13-commands-and-queries-handlers-and-views.html

[dbaber]

I think I ran into something similar and came to the conclusion that I'd rather just generate a seeded uuidv5 and store that as the PK.