DDD在Northwind数据库中的应用

总的来说,我很想回答 Mu (在禅宗意义上),因为从DDD的角度来看,场景是错误的。在DDD中,我们从业务需求和领域专家开始,并从中得出 域模型

也就是说,我会尽力做到最好。

在大多数情况下,订单是一个非常重要的业务对象,显然我们需要了解订单行,包括每一行中的产品,因此我们似乎需要从订单行(订单详细信息)到产品的关联。

然而,当给定一个特定的产品时,我们很少需要知道它包含在哪个订单中,所以这就意味着一种单向关系。我们可以从订单行导航到产品,但不能从产品导航到订单行。

然而,上述分析在更深层次上可能是错误的。想象一下开发人员和领域专家之间的以下对话:

我们创建了从订单到产品的关联,以便我们始终了解特定订单中产品的所有信息。

听起来不错,但供应商呢?

开发人员: 这也包括在内。

实验: 那么,当我们更换产品的供应商时会发生什么?

开发人员:

这不是我们想要的。我们希望数据反映发货时的订单。

这种情况可能会建议将订单行与产品之间的关联完全切断。订单应保存历史(快照)产品数据,而不是当前产品数据。

ProductSnapshot 价值对象 在语义上反映 Product 在域模型中对此进行建模。

Order 作为自身和订单行的集合(带有 ProductSnapShots

据我目前了解的关联和聚合, 关联定义聚合 . 如果有订单,我们想了解客户的情况吗?很有可能。如果有客户,您想知道订单的情况吗?可能

这意味着一种双向关系,这使得 Customer 这个 . 这意味着你会有一个 CustomerRepository OrderRepository . 每次您需要订单时,都必须通过 顾客 .

在某些情况下,这可能是完全合理的,而在其他情况下,这可能真的很笨拙。这取决于业务需求。。。

你可以考虑创建一个 也一样,但这侵犯了 聚合根。如果你这么做了,订单的责任就变得模糊了。如果你从订单到客户唠叨会发生什么? 订单存储库 ?

可能不会,但如果您从 客户储蓄 . 这里的重点是对 聚合根 这一点很重要,一旦定义了聚合,就必须坚持并尊重它。

所以我 喜欢小骨料 在这个例子中,我将把聚合限制为 订单 和它的订单行之间没有关联 订单 和 顾客 .

之间没有正式的联系 订单 和 顾客 这并不意味着我们不能把它们联系起来,但我们需要明确的解释 服务 向我们提供给定客户的所有订单。我们不能只是从一个导航到另一个。