Security DDD和授权相关对象作为聚合根？

我想知道是否应该将依赖对象建模为聚合根。假设我有一个

任务列表

，这个列表有

任务

s。如果没有任务列表，

任务

就不能存在，但可以单独查看和编辑。在修改或添加任务时，

任务列表

不会检查任何特殊条件，我认为这是聚合根的主要原因。唯一的条件是，

任务列表及其任务只能由所有者编辑。如果
任务列表
有所有者，并且只能通过任务列表编辑任务，则很容易确保这种情况。否则，我将需要跨活动地检测所有者或向任务添加所有者字段

那么什么才是合适的呢


任务和任务列表都作为聚合根，并且每个根都有一个所有者字段
仅将任务列表作为聚合根，并将任务作为从属实体

我错过了什么重要的东西吗？

如果两者都没有不变量，则将它们设计为单独的聚合
任务列表是任务的工厂，因此允许它告诉任务谁是任务的所有者。现在，任务的任何后续行为都可以验证它们是由适当的所有者执行的（即，任务应该记住列表告诉所有者的内容）。然而，从用户体验的角度来看，这似乎是糟糕的设计。为什么要对用户不是其所有者的任务启用“编辑”按钮（或将详细信息显示为可编辑）？是的，中间人的攻击是可能的。但你愿意在这方面花费多少时间/金钱（有多重要）
至于授权，一定要问这在你的模型中占多大比例。不是说它不是或是，只是想一想
有关聚合设计的更多信息，请参见：
&

我会这样做：

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);
 }
}

你在哪里看到中间人攻击的可能性？UI和执行任务行为的部分之间的任何东西。