There is value in this, but the reasoning is beyond silly.

You want to use locally generated uuid's (you should always use v4 for that) because:

1. you don't want to rely on 3rd party software for this -> why not for this? Ok, generally 3rd party software can pose problems (updates / security / availability / etc) but here we are talking about your storage, which are going to use anyway. Also, the very generator you are using (unless you wrote your own implementation of uuid) is a 3rd party software. Also, most/all RDBMS can generate uuid's as well, the fact that you call uuid() in your code makes no difference unless you actually plan to not use an RDBMS.

2. don't use setters, plan and simple. You can generate an id and still write a setter out of habit. Has nothing to do with anything.

3. are you unit testing your entities? Seriously? Given your examples, what exactly are you unit testing? Getters? Setters? Because for anything beyond that, your entities and everything else except the thing you are unit testing MUST be mocked, otherwise you're not testing the unit but also a bunch of dependencies.

So ... you have no reasons, actually.

Also:

- you say the uuids need not be the primary keys, but if so, what's the point? Primary keys are what identifies an entity for the db and for your ORM. How would you do your data fetching? By uuid, of course, meaning that your uuid should still be a key / index at least, but uuids are long strings - the most inefficient type for a key.

- generating the way you show is not scalable. If you have 2 instances of your app, using the same generator library (presumably seeded the same way) increases the chances of collisions. An uuid v4 has virtually no chances of collisions if ran sequentially a million times, but run the same generator in parallel and there's more than a fair chance.

But let me help ....

- the basic generated key in most rdbms is an auto increment, which can be a security risk if used in a context where they may be exposed (URLs / logs)

- generating in a rdbms can pose a performance issue. If you want to create two related entities, you need 2 db calls with different transactions (save first, get the id then update and save the second). Generating at application level allows you to save everything at once .

- to make it scalable you can run an id generator service next to your applications.