DDD и авторизационно-зависимые объекты как совокупные корни?

Question

Интересно, должен ли я моделировать зависимые объекты как совокупные корни. Допустим, у меня есть TaskList, а в этом списке Task с. Task не может существовать без TaskList, но его можно просматривать и редактировать отдельно. Нет никаких особых условий, которые TaskList мог бы проверять, когда Задача изменена или добавлена ​​- что, я думаю, было бы основной причиной совокупного корня. Единственное условие - TaskList и его задачи могут редактироваться только владельцем. Было бы легко обеспечить это условие, если бы у TaskList был владелец, а задачи можно было редактировать только через TaskList. В противном случае мне нужно было бы определить владельца транзитивно или добавить поле владельца в задачи.

Так что здесь уместно?

• Task и TaskList как совокупные корни и каждый с полем владельца
• Только TaskList в качестве совокупного корня и Задачи в качестве зависимых объектов

Я что-то упустил?

Answer 1

• Если нет никаких инвариантов, управляющих обоими, проектируйте их как отдельные агрегаты.
• Список задач - это фабрика задач, что позволяет ему определить, кто является владельцем задачи. Любое последующее поведение задачи теперь может проверить, что оно выполнено надлежащим владельцем (то есть задача должна помнить, что список сообщил владельцу). Тем не менее, это выглядит как плохой дизайн с точки зрения UX. Зачем включать кнопку редактирования (или показывать детали как редактируемые) для задач, владельцем которых не является пользователь? Да, человек в середине атаки возможен. Но сколько времени / денег вы готовы потратить на это (насколько это важно)?
• Что касается авторизации, задайте вопрос, сколько это входит в вашу модель. Не говорить, что это не так, просто подумать.
• Подробнее о дизайне агрегатов можно узнать здесь: Эффективный совокупный дизайн & Повышение производительности и масштабируемости с помощью 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);
 }
}