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