Question

我想知道是否应该将依赖对象建模为聚合根。假设我有一个TaskList，此列表中包含Task个。没有Task，TaskList不能存在，但可以单独查看和编辑。我认为，TaskList没有特殊条件可以检查修改或添加任务的时间 - 这将是聚合根的主要原因。唯一的条件是，TaskList及其任务只能由所有者编辑。如果TaskList拥有所有者并且只能通过TaskList编辑任务，那么很容易确保这种情况。否则，我需要以交叉方式检测所有者或向任务添加所有者字段。

那么这里适当的是什么？

任务和任务列表既可以作为聚合根，也可以作为所有者字段
只有TaskList作为聚合根，而任务作为依赖实体

我错过了重要的事情吗？

Answer 1

如果没有控制两者的不变量，请将它们设计为单独的聚合。
任务列表是任务的工厂，因此允许它告诉任务所有者是谁。任务的任何后续行为现在都可以验证它们是由适当的所有者执行的（即任务应该记住列表告诉所有者的内容）。然而，从UX的角度看，这似乎是糟糕的设计。为什么在用户不是所有者的任务上启用编辑按钮（或将详细信息显示为可编辑）？是的，中间人可能会受到攻击。但是你愿意花多少时间/金钱（这有多重要）？
至于授权，请询问您的模型中有多少。不是说它不是或者只是要考虑的东西。
有关聚合设计的更多信息，请点击此处： Effective Aggregate Design＆amp; Improving performance and scalability with DDD

Answer 2

我会这样做：

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

DDD和授权依赖对象作为聚合根？

2 个答案: