DDD和授權依賴對象作爲聚合根源？

我不知道是否應該將依賴對象建模爲聚合根。假設我有一個TaskList，並且此列表有Task s。 A Task不能存在沒有TaskList但它可以單獨查看和編輯。 TaskList可以檢查何時修改或添加任務的特殊條件 - 我認爲這將是聚合根的主要原因。唯一的條件是，TaskList及其任務只能由所有者編輯。如果TaskList擁有所有者並且只能通過任務列表編輯任務，那麼確保這種情況很容易。否則，我將需要transetivly檢測所有者或添加一個所有者字段的任務。DDD和授權依賴對象作爲聚合根源？

那麼這裏有什麼合適的？

任務和任務列表既作爲總根，每一個業主現場
只有任務列表作爲聚合根和任務相關的實體

我失去了一些重要的東西？

來源

2011-11-03 deamon

如果沒有不變量控制兩者，則將它們設計爲單獨的聚合。
任務列表是任務的工廠，因此允許它告知任務誰是任務的所有者。任務的任何後續行爲現在都可以驗證它們是否由正確的所有者執行（即任務應該記住列表告訴所有者是什麼）。不過，從UX的角度來看，這似乎是糟糕的設計。爲什麼啓用編輯按鈕（或顯示可編輯的細節）用戶不是所有者的任務？是的，一箇中間人攻擊是可能的。但是你願意花多少時間/金錢（這有多關鍵）？
至於授權，請問你的模型有多少是你的模型的一部分。不是說它不是或者只是需要思考的東西。
更多的聚集設計可以在這裏找到： Effective Aggregate Design & Improving performance and scalability with DDD

來源

2011-11-03 10:28:54

你在哪裏看到在中間人攻擊的可能性？ – deamon

您的用戶界面和執行任務行爲的部分之間的任何內容。 –

我會做這樣的：

class TaskList{ 
User Owner; 
Task[] Tasks; 
} 

class Task{ 
TaskList List; string Description; 
void ChangeDescription(description){ 
    if(List.Owner!=CurrentUser) 
    throw exception or whatever; 
    else 
    Description=description; 
} 
} 

// http post 
class TaskController{ 
ActionResult ChangeDescription(int id, string description){ 
    _tasks.Find(id).ChangeDescription(description); 
} 
}

來源

2011-11-09 14:50:12

DDD和授權依賴對象作爲聚合根源？

回答

相關問題