在设计领域模型时，是否有一些经验法则，在哪个方向进行关联？
例如，我们有库存产品。产品的库存状态是一个相当复杂的数据结构，包含产品的多种变体的枚举，无论是在库存中、缺货还是可预订。因此，我们制作了与产品相关的库存状态的单独对象。 现在的问题是，产品对象是否应该引用它的库存状态，或者库存状态应该引用特定产品。
第一个解决方案的感觉是，知道它的库存状态并不是产品真正关心的问题。产品只是一个产品，也许我们应该在不同的环境中操纵它们，而库存不是问题。另一方面，库存状态是一个根让人感觉很尴尬，因为在考虑库存时，我们首先考虑产品是否在库存中。
如何决定，哪个实体作为关联的根？
【问题讨论】：
标签： oop design-patterns architecture uml domain-driven-design
您假设这两个概念是紧密耦合的，也就是说，它们属于同一个有界上下文。这意味着两个模型变得相互依赖——这可能是您不想要的，因为它会导致您可能不想要的复杂性。毕竟，您自己提到过：“知道它的库存状态并不是产品真正关心的问题”。那么为什么要添加关系呢？
您可以将它们视为两个独立的有界上下文 - 它们之间没有直接关系，除了链接这两个概念的产品 ID。
【讨论】：
导航性是你应该忽略的东西，因为它纯粹是人为的。如果两件事是相关的，他们就互相了解。行动与反应。重力。爱。努力寻找只在一个方向上起作用的东西。勒索。间谍镜子。
引入可导航性确实只在实施阶段有意义。您尝试将事物解耦以减少依赖关系，现在是永远。而您在这里实际要做的是将角色名称附加到导航中。这反过来又使箭头变得多余。
TL;DR;只是不要在 UML 建模中使用箭头。把它们留给 Powerpoint League。
【讨论】：
第一个解决方案的感觉是，知道它的库存状态并不是产品真正关心的问题。产品只是一个产品，也许我们应该在不同的环境中操纵它们，而库存不是问题。另一方面，库存状态作为根让人感觉很尴尬，因为在考虑库存时，我们首先会想到库存中的产品。
当我们想到购物车时，我们会想到购物车中的产品。然而大多数时候，对购物车商品建模的有用方法是参考产品。
我的猜测是你需要更多地考虑Stock，尤其是它的生命周期；这两种不同想法的生命周期有多紧密？如果您遇到单个 Product 与两个不同的 Stocks 相关的情况（一个在过去，一个在现在；一个在此位置，另一个在该位置），则将该关系存储在产品中不对。
【讨论】：