A continuation on the Messy Event Flows series (if you could call it that). You don't need to read it first, but if you're interested, give it a ...
For further actions, you may consider blocking this person and/or reporting abuse
Another way to do this is to have a pre-populated set of unique identifiers (per category) in a FIFO queue and just have the book creation command take the next unique identifier off the queue.
That way your "uniqueness test" can run before the important time dependent and money generating functions of adding the book.
I hadn't thought of that. There's nothing in the constraint that says the number can't be generated before the book. A queue is a really nice solution to that problem.
The prepopulated queue of unique ids is a good solution for massively distributed systems as you can split the queue by region.
Would using something like a generated UUID work for this case as well? I realize that you're more trying to illustrate how to deal with constraints in DDD, and for the email case... UUID clearly won't fit! Nice post, thanks!
Thanks Gabriel.
In the above case the book number is an incrementing number (which I probably didn't make clear) that is used by people to reference the book, not the system. Internally books are given UUIDs on creation, so the system can reference them, but UUIDs are not human friendly, so we also generate the book number.
UUIDs really are a life saver in these kind of systems, I honestly can't live without them anymore.
Ahhh, thanks I must have missed that on my first read!
Nice article! The part in which you talk about relaxing constraints is a nice piece of advice.
I do think that the projection it's a bit overkill though. Have you consider other solutions to generate the increasing number, like DynamoDB atomic counter?
Dynamo it's a life saver :)
docs.aws.amazon.com/amazondynamodb...