>分配后端提供的密钥(NDB,MySQL等).
>通过一些服务(如系统时钟)手工制作唯一标识符.
>像emailId这样的属性.
举一个详细视图的简单示例,我们经常会像/ some / users / {user_id}那样详细显示用户,如果我们将emailId保持为唯一ID,那么用户可能会更改其电子邮件ID一天,打破它.
哪种方法可以更好地识别同一个实体？
命名为UUID.UUID,因为它为标识符提供了一个很好的可预测结构,而没有引入任何语义含义(比如你的电子邮件ID示例).想想surrogate key.
命名为UUID,因为您希望生成的id是确定性的.确定性意味着可重现：您可以将系统移动到测试环境,并重放命令以检查结果.
它还为您提供了一种检测重复工作的额外方法 – 如果重复创建用户命令,系统中应该发生什么(例如：用户对同一个Web表单进行两次POST).您可以通过各种方式在中间层中防范这种情况,但在持久层(也就是在您的记录系统中)中覆盖此方法的一种非常简单的方法是在id上添加唯一性约束.因为第二次运行命令会生成具有相同id的“新”用户实体,所以持久层将反对复制,您可以从那里处理事务.
因此,即使所有中间保护层在重复命令之间的间隔期间重新启动,您也会获得幂等命令处理.
命名的UUID为您提供这些属性;例如,您可以从实体类型的标识符和命令的id构建uuid(重复命令在重新发送时将具有相同的id).
如果您保证不会将属性分配给其他人,则可以将用户的瞬态属性(如电子邮件地址)用作命名uuid的种子的一部分.您确定vivek@stackoverflow.com不会被分配给其他用户吗？那么它不是一个好的种子.
如果命令重复,后端键分配将不会检测到冲突 – 您需要依赖其他一些状态来检测冲突.
系统时钟不是一个好的选择,因为它使得重现相同的id很困难.如果您可以在测试环境中重现对本地时钟的更新,则系统时钟的本地副本可以工作.但如果时间不是您的域模型的一部分,那么这是您不想要的额外努力.
> https://www.ietf.org/rfc/rfc4122.txt(第4.3节)
> http://www.rfc-editor.org/errata_search.php?rfc=4122&eid=1352(勘误表中的示例)
> Generating v5 UUID. What is name and namespace?