尽管这是一个有争议的观点,但数据库几乎只是业务需求的偶然工件(几乎总是声明实体必须保持不变).

那就是说,我会努力做到最好.

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

但是,当给定特定产品时,我们很少需要知道它包含在哪个订单中,因此建议在那里建立单向关系.我们可以从订单行导航到产品,但不能从产品到订单行.

但是,上述分析可能在更深层次上被证明是错误的.想象一下开发人员和领域专家之间的以下对话：

开发：我们已经从订单到产品创建了这种关联,这样我们就可以按特定顺序了解产品的所有信息.

Exp：听起来不错,但供应商怎么样？

开发：也包括在内.

Exp：那么当我们更换产品供应商时会发生什么？

开发：这也将隐含地反映在订单数据中……

Exp：那不是我们想要的.我们希望数据反映我们发货时的订单.

在这种情况下,事实证明数据库模式实际上存在错误.问题可能是由报告引起的,因为业务分析师可能希望运行有关不同供应商如何影响收益的报告(我知道什么).

这种情况可能建议完全从订单线到产品的关联.订单应包含历史(快照)产品数据,而不是当前产品数据.

我们甚至可以引入ProductSnapshot Value Object,它在语义上镜像产品实体,以便在域模型中对此进行建模.

总而言之,将Order建模为自身和订单行(使用ProductSnapShots)的聚合似乎越来越合理,但订单与客户之间的关系又如何呢？

由于我目前了解关联和聚合,关联定义聚合.给定订单,我们想了解客户吗？最有可能的.鉴于客户,您想了解订单吗？大概.

这表明双向关系,这使客户成为聚合根.这意味着您将拥有CustomerRepository,但没有OrderRepository.每次需要订单时,您都必须通过客户获得订单.

在某些情况下,这可能是完全合理的,而在其他情况下这可能非常笨重.这真的取决于业务要求……

您也可以考虑创建OrderRepository,但这会侵入Customer Aggregate Root.如果你这样做,那么对秩序的责任就会变得含糊不清.如果您从订单到客户,会发生什么？客户有一个订单列表,但是如果您从OrderRepository读取订单,它们是否都填充在内存中？

可能不是,但如果您从CustomerRepository中读取客户,则可能是这样.这里的要点是对Aggregate Roots的分析很重要,一旦你定义了Aggregate,你就必须坚持下去并尊重它.

这使得我倾向于小聚合而不是大聚合,所以在这个例子中,我会将聚合约束为Order及其订单行,并且Order和Customer之间没有关联.

订单和客户之间没有正式关联并不意味着我们根本无法联系它们,但我们需要明确的服务来为我们提供给定客户的所有订单.我们不能只从一个导航到另一个.