我们正在学习 DDD 并评估其在由遗留系统和数据存储支持的系统中的用途。
我们一直在使用 Anti-Corruption Layer、Bubble Context 和 Bounded Context 却不知道它们，这种方法对我们来说似乎很实用。
但我们对识别方法和身份相关性并没有把握和信心。旧数据存储没有主键，而是使用复合唯一索引来标识信息。
我们目前正在将模型创建为应该是实体的值对象（希望为每个对象添加“Long id”字段），或者我们很少使用唯一索引中使用的属性组合作为 id 字段。我们似乎很清楚实体模型应该有 id 字段。
以下是我的具体问题：
- 我们希望我们闪亮的新实体在理论上具有“Long id”字段。现在不添加该字段是否可以，因为这没有给我们任何价值，因为后端数据存储不会填充或理解该字段？
- 是否可以以 DDD 方式存储标识信息并在稍后的某个时间对其进行重构，希望数据存储能够满足我们的需求。
- 如果是这样，从实体中抽象标识是好的方法（我的意思是可识别接口，还是每个实体的 KeyClass？-这里需要任何好的建议..）
- 这个问题可能超出了 DDD 的范围，但我想知道识别重构是否会对系统的多个层造成影响（例如，REST api 可能从/entity/id_field/id_field/id_field 更改为/entity/new_long_id）
和其他问题：
我们如何将遗留信息用于我们不断发展的完善的域模型，同时减少识别问题的痛苦？
或者在项目生命的任何时候都希望我们的域拥有Long id是不好的和没有价值的？
我们如何重构身份管理？
更新：
- 身份管理是 DDD 的重要方面，还是可以重构的基础设施方面，所以我们不应该花更多时间在上面？