many-to-many - DDD : nested aggregates and many to many relationships

Question

我目前正在研究发布有界上下文。这方面的主要参与者是产品 和 上市 .

产品:可以在多个市场上列出。一 产品 许多 上市 .

列表:可以有很多产品，因为某些市场支持变体列表。一 上市 许多 产品 .

基于以上，我在 之间建立了多对多关系。上市 和 产品 .

我为两者创建了一个聚合。包含列表的产品聚合和包含产品的列表聚合。

可以接受上市 在两个聚合中定义还是应该定义 Listing 一次以在两个聚合中使用？

第一 上市 将在产品聚合中，因为产品 AR 具有在创建 Listing 时强制执行规则的工厂方法(例如避免在同一市场中重复列出并确保我们有库存数量可用于列出)

第二 上市 将是一个聚合根，它可以包含来自许多 的信息产品 发布时需要。通过这种方式，我可以在 Listing 上创建方法以将其映射到不同市场(例如 Ebay 和 Amazon)提供的架构定义。此外，我希望能够独立于同一产品中的列表保留列表。

这两个聚合是否与重复定义有太多重叠？这是在一个有界上下文中预期的吗？

另外我怎样才能保持列表的重复表示相互同步？

Answer 1

First Listing would be within the product aggregate because the product AR has a factory method that enforces rules when creating Listing(such as avoid duplicate listing in same marketplace and ensure we have stock qty for listing)

产品是否应该知道自己的库存、自己的市场、自己的列表并创建列表？这对一个实体来说责任太大了!我建议让 ListingFactory 使用保存此信息的其他服务或存储库检查股票和市场。

Is it acceptable to have Listing defined in both aggregates or should I define Listing once to be used in both aggregates? Also how can I keep the duplicate representation of Listing synchronize with each other?

通过维护单个列表来避免产品和列表之间的循环依赖和困惑(查看这个问题以获得类似的纠结: How to design many-to-many relationships on deletion? )。在我看来，您应该拥有一个包含您的列表的市场集合。如果您需要访问基于产品的所有列表(如我提议的 ListingFactory)，您可以设置一个市场服务或存储库来获取所有列表。

Do the two aggregates have too much overlap with duplicate definitions ?

你对产品“可以在多个市场上市”的定义并不是一个非常令人满意的定义，因为在阅读了这个定义之后，问题仍然存在:那么什么是可以上市的？就其核心而言，可以在不了解列表的情况下定义产品，但在这种情况下，明确命名关系可能仍然更好。因为没有产品就不能定义(产品)listing，但是没有listing就可以定义产品。它们不必是重复的。我希望您的产品完全不知道列表，但与上下文中的列表相关。

Is this to be expected within one bounded context?

所有的定义都是相互建立的，所以在任何上下文中，你都可以期待重叠、重复、同义词、扩展、近似相似、交叉引用、不同类型的关系等。 将主要的和主要的分开需要相当多的调查意识。其次，谓语来自主语和宾语，核来自膜。然而，这也是让它如此有趣的原因:)

词的定义:“一个单独的、有意义的言语或写作元素，与其他人(或有时单独)一起构成一个句子。”

句子的定义:“一组本身完整的词，通常包含一个主语和谓语，传达一个陈述、疑问、感叹……”