Before lambasting Tom too much over the security concern... indeed, we should have proper auth&auth controls to prevent malicious request tampering, but also keep in mind that we should be employing multiple layers of defense with our security strategy. All else being equal, an ID schema that makes request tampering difficult will be more secure than one that invites it.

With that said, the security issue alone is probably not reason to avoid using auto-incrementing numeric IDs. But there is actually another reason that isn't even mentioned in this article. Namely, we might need our entities' IDs to be generated somewhere other than our database (even if not now, then perhaps in the future). I've run into this issue on multiple different projects, so I know it's not theoretical, and probably much more likely than the merging-databases scenario.

Speaking of, I have encountered that latter problem as well, and can attest that having ID collisions when merging two databases can be the thing of nightmares. Again, it might not seem like a concern with a newer system. And the person you'd eventually be horking over would not be yourself, but some poor engineer tasked years later with integrating some newly-purchases company's database. But again, it's worthy of consideration.

And finally, I'd assert that any discussion like this should throw in the idea of aggregates. If we design our entities as aggregates, then that allows us to worry primarily about how we generate the IDs of our *aggregate roots* — in most cases, we can safely continue to allow our value objects' IDs to be auto-generated by our database of choice.

This article probably shouldn't have been titled "Stop Using...", but rather, "Consider Not Using..." Likewise, however, anyone suggesting that autogenerated IDs should *always* be used is not recognizing that there are real-world considerations and trade-offs that often need to be made.