我目前正致力于发布有限上下文。这方面的主要参与者是产品和列表。
产品：可在多个市场上市。一个产品多个列表。
清单：可以有很多产品，因为一些市场支持变体列表。一个列表多个产品。
基于以上所述，我在列表和产品之间存在多对多关系。
我为两者创建了一个聚合。包含列表的Product聚合和包含产品的Listing Aggregate。
在两个聚合中定义列表是否可以接受，或者我应该将List一次定义为在两个聚合中使用？
首先列表将在产品聚合中，因为产品AR具有在创建列表时强制执行规则的工厂方法（例如避免在同一市场中重复列出并确保我们有库存数量用于列表）
第二个列表将是一个聚合根，它可以包含发布时所需的许多产品的信息。这样我就可以在Listing上创建方法，将其映射到不同市场（如Ebay和亚马逊）提供的模式定义。此外，我希望能够独立于同一产品中的列表保持列表。
这两个聚合是否与重复定义有太多重叠？这是在一个有限的背景下预期的吗？
另外，我如何保持列表的重复表示彼此同步？
答案 0 :(得分：1)
首次列表将在产品聚合中，因为产品AR具有在创建列表时强制执行规则的工厂方法（例如避免在同一市场中重复列出并确保我们有库存数量用于列表）
产品是否应该知道自己的股票，自己的市场，自己的列表和创建列表？这对一个实体来说太过分了！我建议让一个ListingFactory检查股票和市场信息以及其他包含此信息的服务或存储库。
是否可以在两个聚合中定义Listing，或者我是否应该在两个聚合中使用List一次？另外，我如何保持列表的重复表示彼此同步？
通过维护单个列表来避免产品和列表之间的循环依赖以及混乱（请查看此问题以获得类似的纠结：How to design many-to-many relationships on deletion?）。在我看来，你应该有一个市场集合，其中包含你的列表。如果您需要根据产品访问所有列表（例如我建议的ListingFactory），您可以设置获取所有列表的市场服务或存储库。
这两个聚合是否与重复定义有太多重叠？
您对产品的定义“可以在多个市场中列出”并不是一个非常令人满意的定义，因为在阅读了这个定义后，问题仍然存在：那么它可以列出什么呢？从本质上讲，可以在不知道列表的情况下定义产品，但在此上下文中，明确命名关系可能仍然会更好。由于无法在没有产品的情况下定义（产品）列表，但可以在没有列表的情况下定义产品。它们不需要重复。我希望您的产品完全无法上市，但与上下文中的商家信息相关。
这是在一个有限的背景下预期的吗？
所有定义都是相互依赖的，所以在任何上下文中你都可以期待重叠，重复，同义词，扩展，近似相似，交叉引用，不同类型的关系等。它需要相当多的调查意识来分离来自次要的初级，来自受试者和对象的谓词，来自膜的核。然而，这也是让它如此有趣的原因：）
单词的定义：“一个独特的有意义的言语或写作元素，与其他人（或有时单独使用）一起形成一个句子......”
句子的定义：“一组本身完整的单词，通常包含主语和谓语，表达语句，问题，感叹......”