oop – 何时以及如何为DDD中的实体分配唯一ID？
|
最好的例子是需要持久化的用户实体.我有以下候选人为用户分配唯一标识符：
>分配后端提供的密钥(NDB,MySQL等). 举一个详细视图的简单示例,我们经常会像/ 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节) （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |