我目前正在研究发布有界上下文。这种情况下的主要参与者是 产品 和 列表 。
产品:可以在多个市场上列出。一个 产品 许多 列表 。
列表:可以有很多产品，因为一些市场支持变体列表。一个 列表 许多 产品 。
基于上述，我在 列表 和 产品 之间存在多对多关系。
我为两者创建了一个聚合。包含列表的产品聚合和包含产品的列表聚合。
在两个聚合中都定义 Listing 是否可以接受，或者我应该定义 Listing 一次以在两个聚合中使用？
第一个 Listing 将在产品聚合中，因为产品 AR 具有在创建 Listing 时强制执行规则的工厂方法(例如避免在同一市场中重复上架并确保我们有用于上架的库存数量)
第二个 列表 将是一个聚合根，它可以包含发布时所需的许多 产品 的信息。通过这种方式，我可以在 Listing 上创建方法以将其映射到不同市场(例如 Ebay 和 Amazon)提供的架构定义。此外，我希望能够独立于同一产品中的列表保留列表。
这两个聚合是否与重复定义有太多重叠？这是在一个有界上下文中预期的吗？
另外我怎样才能保持列表的重复表示相互同步？
最佳答案
产品是否应该知道自己的库存、自己的市场、自己的列表并创建列表？这对一个实体来说责任太大了!我建议让 ListingFactory 使用保存此信息的其他服务或存储库检查股票和市场。
通过维护单个列表避免 Product 和 Listing 之间的循环依赖和困惑(查看这个问题以获得类似的纠结: How to design many-to-many relationships on deletion? )。在我看来，您应该拥有一个包含您的列表的市场集合。如果您需要访问基于产品的所有列表(如我提议的 ListingFactory)，您可以设置一个市场服务或存储库来获取所有列表。
你对产品“可以在多个市场上市”的定义并不是一个非常令人满意的定义，因为在阅读了这个定义之后，问题仍然存在:那么什么是可以上市的？在其核心，可以在不了解列表的情况下定义产品，但在这种情况下，明确命名关系可能仍然更好。因为没有产品就不能定义(产品)listing，但是没有listing就可以定义产品。它们不必是重复的。我希望您的产品完全不知道列表，但与上下文中的列表相关。
所有定义都是相互建立的，因此在任何上下文中，您都可以期待重叠、重复、同义词、扩展、近似相似、交叉引用、不同类型的关系等。 将主要的与原始的分开需要相当多的调查意识其次，谓语来自主语和宾语，核来自膜。然而，这也是让它如此有趣的原因:)
词的定义:“一个单独的、有意义的言语或写作元素，与其他人(或有时单独)一起构成一个句子。”
句子的定义:“一组本身完整的词，通常包含一个主语和谓语，传达一个陈述、疑问、感叹……”
关于many-to-many - DDD : nested aggregates and many to many relationships，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/17933313/