blocks|key|268680|text|通过关注侧栏中链接的相关问题，我发现了这篇有趣的文章：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|268681|DDD+&+Many+to+Many+Object+Relational+Mapping|offset|length|268682|它似乎推荐了我直觉上的想法:工人和任务实际上并不自然地依赖于合同。也就是说，在没有“契约”概念的情况下，“工作者”的概念仍然有意义(对于任务也是如此)，因此包含该概念的实体不应该依赖于契约实体。|268683|要显示分配给给定任务的合同或分配给给定员工的合同，您需要运行域查询。这实际上是对域服务的一种适当的使用，如果您仔细考虑一下，它会更好地反映您的域的实际情况。|268684|我还注意到您说"Contract绝对不是聚合根，因为没有Task和Worker它就没有意义。“这实际上就是契约被为聚合根的确切原因。|style|BOLD|268685|因此，我的建议，结合arootbeer从评论中获得的见解：|268686|📷|atomic|268687|​|268688|entityMap|0|LINK|mutability|MUTABLE|url|http://www.udidahan.com/2009/01/24/ddd-many-to-many-object-relational-mapping/|1|IMAGE|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/7028cd19eb35f28eea86cd6ba8495249.png|imageAlt^0|0|0|18|0|0|0|0|1J|1|0|0|0|1|1|0|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|19|8|@]|9|@$D|1A|E|1B|1|1C]]|A|$]]|$1|F|3|G|5|6|7|1D|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1E|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1F|8|@$D|1G|E|1H|L|M]]|9|@]|A|$]]|$1|N|3|O|5|6|7|1I|8|@]|9|@]|A|$]]|$1|P|3|Q|5|R|7|1J|8|@]|9|@$D|1K|E|1L|1|1M]]|A|$]]|$1|S|3|T|5|6|7|1N|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]]|V|$W|$5|X|Y|Z|A|$10|11]]|12|$5|13|Y|14|A|$15|16|17|-4]]]]

By following related questions linked in the sidebar, I found this interesting article:

<a href="http://www.udidahan.com/2009/01/24/ddd-many-to-many-object-relational-mapping/" rel="noreferrer">DDD &amp; Many to Many Object Relational Mapping</a>

It seems to recommend what I was intuitively thinking anyway: that it is not in fact natural for worker and task to take on a dependence on contract. That is, the concept of a "worker" is still meaningful without the concept of a "contract" (and similarly for task), so the entity embodying that concept should not have a dependency on the contract entity.

To display the contracts assigned to a given task, or the contracts assigned to a given worker, you will need to run a domain query. This is in fact an appropriate use for a domain service, and better reflects the reality of your domain if you think about it.

I also note that you say "Contract is definitely not aggregate root, because it has no sense without Task and Worker." That is actually the precise reason that Contract is the aggregate root.

So, my suggestion, with arootbeer's insight from the comments incorporated:
<img src="https://i.stack.imgur.com/kv4t9.png" alt="Proposed new class diagram">

blocks|key|272319|text|在我看来，Contract在您的设计中是一流的对象。您声称它在worker和task的上下文之外都没有意义，这当然是正确的，但这并不意味着它本身就不是聚合根。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|272320|根据与之相关的task和worker的某些属性，Contract大概有自己的计算成本的逻辑。类似地，Task和Worker包含与Contract无关的上下文。|272321|您需要跳过的间隙是将与相关的上下文移动到Contract对象中。让它存储worker的速率和task的周期(除了上面仅隐式建模的相应it之外)，并动态地计算成本。|BOLD|272322|-编辑--|272323|正如Domenic所说，你的评论是一个很好的后续问题的候选者。但我要说的是，一旦您将Task和Worker+I添加到Contract上，报告就变成了一项微不足道的任务。|272324|entityMap^0|5|8|V|6|12|4|0|7|4|C|6|O|8|1E|4|1J|6|1S|8|0|B|3|K|8|10|6|1A|4|0|0|16|4|1B|6|1M|8|0^^$0|@$1|2|3|4|5|6|7|Q|8|@$9|R|A|S|B|C]|$9|T|A|U|B|C]|$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|X|8|@$9|Y|A|Z|B|C]|$9|10|A|11|B|C]|$9|12|A|13|B|C]|$9|14|A|15|B|C]|$9|16|A|17|B|C]|$9|18|A|19|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1A|8|@$9|1B|A|1C|B|J]|$9|1D|A|1E|B|C]|$9|1F|A|1G|B|C]|$9|1H|A|1I|B|C]]|D|@]|E|$]]|$1|K|3|L|5|6|7|1J|8|@]|D|@]|E|$]]|$1|M|3|N|5|6|7|1K|8|@$9|1L|A|1M|B|C]|$9|1N|A|1O|B|C]|$9|1P|A|1Q|B|C]]|D|@]|E|$]]|$1|O|3|-4|5|6|7|1R|8|@]|D|@]|E|$]]]|P|$]]

<code>Contract</code> appears to me to be a first-class object in your design. Your claim that it doesn't make sense outside of the context of both a <code>worker</code> and a <code>task</code> is certainly true, but that doesn't mean it isn't an aggregate root in its own right. 

Presumably <code>Contract</code> has its own logic for calculating its cost, based on some attributes of the <code>task</code> and <code>worker</code> associated with it. Similarly, there is context that <code>Task</code> and <code>Worker</code> contain that are not relevant to <code>Contract</code>.

The gap you need to jump is moving the relevant context into the <code>Contract</code> object. Let it store the <code>worker</code>'s rate, and the <code>task</code>'s period (in addition to the respective IDs, which are only modeled implicitly above), and calculate cost dynamically.

--EDIT--

As Domenic states, your comment is a good candidate for a follow-up question. But I will say that once you get the <code>Task</code> and <code>Worker</code> IDs onto the <code>Contract</code>, reporting becomes a trivial task.

I'm new to DDD and I'm stuck with many-to-many relationships. E.g. we have two aggregate roots - Tasks and Workers.

Contract is definitely not aggregate root, because it has no sense without Task and Worker. So, it should be part of some aggregate. But which aggregate should it belong to? We need to know both summary costs of all task contracts and summary costs of all worker contracts. And it's natural for me to have contracts collection both in Task and in Worker. 

Well, I can move Costs calculation to domain service, but I afraid it's a step forward to anemic model. Is there common way to deal with many-to-many relationships and preserve reach domain model?

Thanks!

<img src="https://i.stack.imgur.com/vtZuZ.png" alt="Class diagram">

Many-to-many relationships in DDD

我是DDD的新手，我被多对多的关系所困扰。例如，我们有两个聚合根- Tasks和Workers。Contract绝对不是聚合根，因为如果没有Task和Worker，它就没有意义。因此，它应该是某个聚合的一部分。但是它应该属于哪个聚合呢？我们需要知道所有任务合同的汇总成本和所有员工合同的汇总成本。对我来说，在Task和W...

问DDD中的多对多关系
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问DDD中的多对多关系EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问DDD中的多对多关系
EN