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

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

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

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

我们目前正在将模型创建为应该是实体的值对象（希望为每个实体添加“Long id”字段），或者我们很少将唯一索引中使用的属性组合用作id字段。我们似乎很清楚，实体模型应该有id字段

以下是我的具体问题：

• 理论上，我们希望我们闪亮的新实体具有长id字段。现在不添加该字段可以吗，因为这没有给我们任何价值，因为后端数据存储不会填充或理解该字段
• 以DDD的方式存储标识信息并在稍后对其进行重构可以吗？希望数据存储能够根据我们的需要进行更改。
  • 如果是这样的话，从实体中抽象出标识是否是一个好方法（我指的是可识别的接口，或者每个实体的KeyClass？——这里需要任何好的建议。）
• 这个问题可能不在DDD的范围之内，但我想知道标识重构是否会对系统的几个层造成影响（例如，RESTAPI可能会从/entity/id\u field/id\u field/id\u field更改为/entity/new\u long\u id）

和其他问题：

• 我们如何将遗留信息用于我们日益完善的领域模型，从而减少识别工作的痛苦

• 或者在项目生命周期的任何时候都希望长id用于我们的领域，这是不好的、没有价值的吗

• 我们如何重构身份管理

更新：

• 身份管理是DDD的一个重要方面，还是一个可以重构的基础设施方面，所以我们不应该花更多的时间在它上面

---

使用任何符合您需要的标识符，但要现实并预先考虑选择错误标识符的成本和影响。从外部分配标识符并将其与其他信息位一起存储（不考虑格式（guid、long、uuid））是有好处的。是否重构身份管理更多的是进行成本/收益分析。对于遗留系统来说，这是一个选项吗？在什么样的时间范围内，会有两个键并排出现？为什么还要重复使用相同的数据存储？为什么不对它进行分区，这样就可以有并行的数据存储（最坏的情况是，即使在两个存储之间同步数据，最好是在一个方向上）？尝试垂直切片而不是水平切片。HTH.

数据存储远远不是标准化的模式。具有7-8列的组合键将复制到所有位置。若我们可以使用相同的数据替换遗留应用程序，那个么我们就可以重构数据库。但在替换传统应用程序时，我们希望使用我们想要的模型。我们无法预见同步方法的影响，因为我们目前还不完全了解该领域，我们可以在未来使用它，但身份问题正在将我们的注意力从核心领域转移。也许还有一个问题：身份管理是DDD的重要方面，还是可以重构的基础设施方面？所需的模型与数据模型一样？当前的密钥是不可变的吗（我希望如此）？你能做一个映射（根据7/8列的值查找新的长id）并在新的数据存储中使用它吗？不要太在意事物的标识。提供代理身份应该很简单。为什么还要保留旧的标识列呢？对于所需的模型，我指的是以DDD方式构造的实体、值对象和聚合（DDD的第一步）。不幸的是，当前的复合键并不总是不变的。我们可以在同一个或另一个数据存储中映射新的长id和复合id，但一旦遗留应用程序进行操作，我们就必须使这些表与触发器或其他东西保持同步。事实上，我们已经以这种方式使用了一些触发器……旧的标识列无法重构，因为旧的应用程序紧密耦合在它们上面。映射标识列可能是合适的解决方案。。