DDD中的多对多关系

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (34)

我刚接触过DDD,我被很多很多的关系困住了。我们有两个聚合根--任务和工人。

契约绝对不是聚合根,因为没有任务和工作人员,它就没有意义。所以,它应该是某些集合的一部分。但是它应该属于哪一个集合呢?我们需要知道所有任务合同的汇总成本和所有员工合同的汇总成本。对我来说,在任务和工作中收集合同是很自然的。

我可以将成本计算转移到域服务,但恐怕这是向贫血模式前进的一步。是否有共同的方法来处理多到多的关系,并保留REACH域模型?

提问于
用户回答回答于

Contract在我看来是你设计中的一流对象。你声称这在两个worker和一个task当然是真的,但这并不意味着它本身就不是一个聚合根。

想必Contract有自己的计算成本的逻辑,基于taskworker与此相关。同样,也有这样的背景TaskWorker包含与Contract...

你需要跳的空隙是移动相关的上下文Contract对象。让它存储worker的比率task的周期(除了相应的ID(仅在上面隐式建模)之外),并动态计算成本。

-编辑--

正如多梅尼克所言,你的评论是一个很好的后续问题的候选人。但我会说一旦你得到了TaskWorkerID到Contract,报告成为一项琐碎的任务。

用户回答回答于

通过在侧栏中链接的相关问题,我发现了这篇有趣的文章:

http://www.udidahan.com/2009/01/24/ddd-many-to-many-object-relational-mapping/

它似乎推荐了我直觉上的想法:事实上,对工人和任务来说,依赖合同是不自然的。也就是说,“工人”的概念在没有“合同”概念的情况下仍然是有意义的(与任务类似),因此体现这一概念的实体不应依赖合同实体。

若要显示分配给给定任务的合同或分配给给定员工的合同,您需要运行域查询。实际上,这是域服务的适当使用,如果考虑到这一点,就会更好地反映你的领域的实际情况。

我还注意到,说契约绝对不是聚合根,因为没有Task和Worker,它就没有意义。这就是合同的确切原因聚合根。

因此,我的建议,加上arootbiler从评论中得出的见解,包括:

扫码关注云+社区