考虑这个EF持久性模型：
alt text http://blogs.developpeur.org/blogs/tja/NorthwindModel_thumb_4FC6AF51.png
请注意,我们只有实体和双向关系.我想有一个真正的DM尊重DDD.更多,我的DM模型不需要是我的数据库的镜像
>如何改变des关系,在需要时只有一种关系或两种方式.
>是否有任何多对一或一对多的关系可以改为一对一？
>你会如何模拟agregates？
>如果需要,值对象,服务和工厂如何？
我知道可能我应该看看业务需求,看看模型应该如何改变,但希望对此有所了解.
如果我的问题不明确,请不要犹豫,询问细节.
提前致谢.
尽管这是一个有争议的观点,但数据库几乎只是业务需求的偶然工件(几乎总是声明实体必须保持不变).
那就是说,我会努力做到最好.
在大多数情况下,订单是一个非常重要的业务对象,显然我们需要了解订单行,包括每行中的产品,因此我们需要从订单行(Order_Detail)到产品的关联.
但是,当给定特定产品时,我们很少需要知道它包含在哪个订单中,因此建议在那里建立单向关系.我们可以从订单行导航到产品,但不能从产品到订单行.
但是,上述分析可能在更深层次上被证明是错误的.想象一下开发人员和领域专家之间的以下对话：
开发：我们已经从订单到产品创建了这种关联,这样我们就可以按特定顺序了解产品的所有信息.
Exp：听起来不错,但供应商怎么样？
开发：也包括在内.
Exp：那么当我们更换产品供应商时会发生什么？
开发：这也将隐含地反映在订单数据中……
Exp：那不是我们想要的.我们希望数据反映我们发货时的订单.
在这种情况下,事实证明数据库模式实际上存在错误.问题可能是由报告引起的,因为业务分析师可能希望运行有关不同供应商如何影响收益的报告(我知道什么).
这种情况可能建议完全从订单线到产品的关联.订单应包含历史(快照)产品数据,而不是当前产品数据.
我们甚至可以引入ProductSnapshot Value Object,它在语义上镜像产品实体,以便在域模型中对此进行建模.
总而言之,将Order建模为自身和订单行(使用ProductSnapShots)的聚合似乎越来越合理,但订单与客户之间的关系又如何呢？
由于我目前了解关联和聚合,关联定义聚合.给定订单,我们想了解客户吗？最有可能的.鉴于客户,您想了解订单吗？大概.
这表明双向关系,这使客户成为聚合根.这意味着您将拥有CustomerRepository,但没有OrderRepository.每次需要订单时,您都必须通过客户获得订单.
在某些情况下,这可能是完全合理的,而在其他情况下这可能非常笨重.这真的取决于业务要求……
您也可以考虑创建OrderRepository,但这会侵入Customer Aggregate Root.如果你这样做,那么对秩序的责任就会变得含糊不清.如果您从订单到客户,会发生什么？客户有一个订单列表,但是如果您从OrderRepository读取订单,它们是否都填充在内存中？
可能不是,但如果您从CustomerRepository中读取客户,则可能是这样.这里的要点是对Aggregate Roots的分析很重要,一旦你定义了Aggregate,你就必须坚持下去并尊重它.
这使得我倾向于小聚合而不是大聚合,所以在这个例子中,我会将聚合约束为Order及其订单行,并且Order和Customer之间没有关联.
订单和客户之间没有正式关联并不意味着我们根本无法联系它们,但我们需要明确的服务来为我们提供给定客户的所有订单.我们不能只从一个导航到另一个.
