DDD中的多對多關係

我是DDD的新手，並且遇到了多對多的關係。例如。我們有兩個聚合根源 - 任務和工人。DDD中的多對多關係

契約絕對不是聚合根，因爲沒有任務和工作者，它就沒有意義。所以，它應該是某些聚合的一部分。但它屬於哪個聚合體？我們需要知道所有任務合同的概要成本和所有工人合同的概要成本。我很自然地在Task和Worker中收集合約。

那麼，我可以將成本計算轉移到域服務，但我擔心這是向貧血模型邁出的一步。處理多對多關係和保留覆蓋範圍模型有沒有常見的方法？

謝謝！

Class diagram

來源

2011-04-27 Sergey Berezovskiy

一個切題 - 你用什麼來創建該圖？ – cbz 2011-04-27 14:57:22

That's http://yuml.me :) – 2011-04-27 14:58:32

按照在側邊欄鏈接相關的問題，我發現這個有趣的文章：

DDD & Many to Many Object Relational Mapping

這似乎有什麼建議，我直覺地想反正：這不是事實對於工人和承擔依賴合同的任務是自然的。也就是說，「工人」的概念在沒有「合同」概念的情況下仍然是有意義的（對於任務也是如此），因此體現該概念的實體不應該依賴合同實體。

要顯示分配給給定任務的合同或分配給給定工人的合同，您需要運行域查詢。這實際上是一種適用於域名服務的功能，如果您仔細考慮，可以更好地反映出您域名的實際情況。

我還注意到你說「合同絕對不是合計根，因爲沒有任務和工作人員就沒有意義。」這實際上是合同是聚合根的確切原因。

所以，我的建議，從評論arootbeer的見解納入： Proposed new class diagram

來源

2011-04-27 15:01:22 Domenic

我認爲將'GetCosts（）'放在'Task'和'Worker'上混淆了事物 - 既沒有'Task'也沒有'Worker'體現了明確的代價;這明確是「合同」的範疇。「工作人員」擁有「費率」，「任務」擁有「期限」或「持續時間」; 「合同」中兩者的組合指定了「成本」。 'GetCosts（）'可能是一個域搜索聚合函數。 – arootbeer 2011-04-27 15:35:56

@arootbeer：可能是對的！我並沒有很好地理解域的成本部分，所以我只是把它們複製過來。我會編輯它以反映您的洞察力。 – Domenic 2011-04-27 15:37:41

那麼，我正在考慮將Contract作爲Aggregate root。但真正的商業價值不是合同成本 - 它是任務和工作者的總合同成本。所以，當任務和工人都沒有收集合同時，模型就會變得貧乏。我們需要通過服務加載所有合同，並且計算一筆費用。順便說一句，工人沒有收入 - 不同的合同有不同的成本。 – 2011-04-28 08:33:53

Contract看來我要在你的設計一流的對象。你聲稱在worker和task的背景之外沒有任何意義的說法當然是對的，但這並不意味着它不是一個合適的根本。

據推測Contract有它自己的邏輯來計算其成本，基於與它相關的task和worker的一些屬性。同樣，Task和Worker包含與Contract無關的上下文。

您需要跳過的間隙是將相關上下文移動到Contract對象中。讓它存儲worker的費率和task的期間（除了相應的ID，這些ID僅在上面隱式建模），並動態計算費用。

- 編輯 -

由於Domenic指出，您的評論是一個後續問題一個很好的候選人。但是我會說，一旦您將Task和Worker ID添加到Contract上，報告就變成一項簡單的任務。

來源

2011-04-27 15:10:24 arootbeer

這只是一個例子。因此，我們可以將合同視爲一個實體，無需成本計算邏輯 - 爲工作支付的簡單金額。是否有辦法爲總任務/員工成本計算建立覆蓋模型？ – 2011-04-28 08:40:43

@lazyberezovsky這是一個很好的問題---絕對要求它作爲後續行動，因爲它有點偏離。當你澄清商業價值是這樣工作的時候，它確實讓我重新思考，我不確定我會做什麼...... – Domenic 2011-04-28 13:31:08

@lazyberezovsky - 檢查我的編輯。 – arootbeer 2011-04-28 16:36:35

DDD中的多對多關係

回答

相關問題