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