在 DDD 中，聚合不变量是否可以包含基于另一个聚合中信息的规则？现在我不这么认为，但是这给我带来了一个问题，我不知道如何解决它。
我有一个名为 Asset(设备)的实体，我将其建模为聚合的根。它有一个标签(属性)列表，用于描述制造商、模型等内容。它存储称为 AssetType 的第二个聚合的标识，该聚合具有一个 TagType 列表，其中一些可以标记为强制性的。
现在在我看来，Asset 的不变条件之一应该引用关联的 AssetType 以在强制标记列表中强制执行非空值。但是我的胆量正在爬上我将如何强制执行一致性的想法。
这是否意味着聚合真的应该包含所有四个实体？如果根是 AssetType 并且它下面有一个 Assets 列表，它可以解决我的问题，但是这不太适合具有其他聚合维护不同类型 Asset 列表的核心用例。 Assets 确实必须是根，否则我会遇到问题。
而且 AssetType 也不能很好地进入 Asset 聚合。这似乎同样荒谬。
我的胆量仍然说 Asset 和 AssetType 是两个独立的聚合，但我该如何解决一致性问题？还是我弄错了不变量？
最佳答案
在这种情况下，有几种方法可以强制执行不变量。
首先，考虑 Asset 周围的行为。总计的。我假设至少有一个 CreateAssetCommand和 RemoveTagCommand .在执行这些命令期间，应通过以下方式强制执行不变量:
创建 Assets 命令
由于 Assets 始终与 Assets 类型相关联，因此 AssetTypeId必须作为此命令的一部分提供。此 ID 必须由调用者获取，可能通过查找特定 Assets 类型来获取。当AssetType查了一下，对应的TagType实体也可以被检索，尤其是强制性的。这将允许调用者构造所需的 Tag作为命令的一部分发送的实例。请注意，调用者有责任提供有效的 Assets 类型和标签。
删除标签命令
此命令的处理程序可以检索适当的 Asset其中存储 AssetTypeId .接下来，处理程序检索 Assets 类型的强制标签集，并确保不会删除这些标签。在这种情况下，不变量由处理程序本身强制执行。
处理这些不变量的另一种方法是引入 eventual consistency ，如果可以接受的话。使用这种方法，从 Assets 中删除标签应发布 TagRemovedEvent .然后，此事件的处理程序可以验证未删除强制标记。如果是，它可以创建一个任务或通知，说明 Assets 处于无效状态。请注意，这假定 Assets 处于无效状态是可以接受的，直到某些事情得到纠正。
现在谈谈 AssetType 周围的行为.一个可能损害 Asset 完整性的命令聚合是引入了一个新的强制性Tag .在这种情况下，确保完整性的唯一方法是为每个相应的 Assets 创建适当的标签。由于这可能无法自动完成，因此必须接受最终的一致性，直到通过手动干预提供适当的标签。
使用所有这些方法，您将无法获得使用 RDMS 所获得的那种完整性。强制执行交叉聚合不变量的责任委托(delegate)给命令处理程序、事件处理程序和调用代码。然而，在许多情况下，这种一致性是完全可以接受的。
看看Effective Aggregate Design了解更多信息。
关于domain-driven-design - 聚合不变量是否可以包含基于来自其他地方的信息的规则？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/15835604/