ddd - 创建和重构实体的标识字段

Question

我们正在学习DDD并评估其在由遗留系统支持的系统中的使用。数据存储。

我们一直在使用反腐败层，泡泡上下文和有界上下文而不了解它们，这种方法对我们来说似乎非常实用。

但我们对识别方法和身份相关性并不确定和自信。 传统数据存储没有主键，而是使用复合唯一索引来标识信息。

我们当前正在创建我们的模型作为Value对象，它们应该是Entities（希望为每个都添加“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的重要方面，还是可以重构的基础设施方面，所以我们不应该花更多时间在其中？

Answer 1

使用符合您需求的任何标识符，但要对选择错误的标签的成本和含义保持现实和前瞻性。从外部分配标识符并将其存储在其他信息位（无论格式如何（guid，long，uuid））都是有用的。是否重构身份管理更多的是进行成本/收益分析。它甚至是遗留系统的一个选项，在什么样的时间范围内有两个键侧面？为什么你甚至重用相同的数据存储区？为什么不对它进行分区，以便您可以拥有并行数据存储（最坏的情况是甚至在两个数据存储之间同步数据，最好是在一个方向上）？尝试一些垂直切片而不是水平切片。 HTH。