Luc*_*uke 5 java domain-driven-design java-ee
我正在阅读Eric Evans关于DDD的书,我对以下引用有疑问.equals()如果不使用属性,如何制作方法？我正在使用JPA,并且我有一个唯一的id属性,但在实际持久保存实体之前不会设置.所以你会怎么做？我已经基于属性实现了equals方法,我理解为什么你不应该因为它在我的项目中失败了.
关于实体的部分:
当一个对象通过其标识而不是其属性进行区分时,将该主要对象定义为模型中的定义.保持课堂定义简单,重点关注生命周期的连续性和身份.定义区分每个对象的方法,无论其形式或历史如何.警告要求按属性匹配对象的要求.定义一个保证为每个对象生成唯一结果的操作,可以通过附加保证唯一的符号.这种识别方法可能来自外部,也可能是由系统创建的任意标识符,但它必须与模型中的标识区别相对应.模型必须定义相同的东西意味着什么.
http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215
可能的几种方法：
使用业务密钥。这是最“符合 DDD”的方法。仔细查看领域和业务需求。例如，您的企业如何识别客户？他们使用社会安全号码或电话号码吗？如果是纸质的（没有计算机），您的企业将如何解决这个问题？如果没有自然业务密钥，则创建代理。选择最终的业务密钥并将其用于equals(). DDD 书中有一节专门讨论这个特定问题。
对于没有自然业务密钥的情况，您可以生成 UUID。这在分布式系统中也有一个优势，在这种情况下，您不需要依赖数据库等集中式（并且可能不可用）资源来生成新的 id。
还有一个选项只依赖equals()实体类的默认值。它将比较两个内存位置，在大多数情况下就足够了，因为工作单元（Hibernate Session）保留所有实体（此 ORM 模式称为“身份映射”）。这是不可靠的，因为如果您使用不限于一个 Hibernate Session 范围的实体（例如线程、分离实体等），它就会中断
有趣的是，“官方”DDD 示例使用一个非常轻量级的框架，其中每个实体类都使用一种方法从实体接口派生：
boolean sameIdentityAs(T other)
// Entities compare by identity, not by attributes.