DDD et les objets dépendants de l'autorisation en tant que racines agrégées?

Question

Je me demande si je devrais modéliser des objets dépendants en tant que racines agrégées. Disons que j'ai un TaskList et que cette liste a Task s. Un Task ne peut pas exister sans TaskList mais il peut être affiché et édité séparément. Il n'y a pas de conditions spéciales que le TaskList pourrait vérifier quand une tâche est modifiée ou ajoutée - ce qui serait la raison principale pour une racine agrégée, je pense. La seule condition est que le TaskList et ses tâches ne puissent être modifiés que par le propriétaire. Il serait facile de garantir cette condition si le TaskList avait un propriétaire et que les tâches ne pouvaient être éditées que via la TaskList. Sinon, je devrais détecter le propriétaire transetivly ou ajouter un champ propriétaire aux tâches.

Alors qu'est-ce qui est approprié ici?

• Tâche et TaskList à la fois comme des racines globales et chacun avec un champ propriétaire
• Seulement TaskList en tant que root globale et tâches comme des entités dépendantes

Suis-je manque quelque chose d'important?

Answer 1

• S'il n'y a pas d'invariants régissant les deux, les concevoir comme des agrégats séparés.
• La liste des tâches est l'usine des tâches, ce qui lui permet de dire à la tâche qui est le propriétaire de la tâche. Tous les comportements ultérieurs de la tâche peuvent maintenant vérifier qu'ils sont effectués par le propriétaire approprié (c'est-à-dire que la tâche doit se souvenir de ce que la liste a dit au propriétaire). Cependant, cela ressemble à un mauvais design d'un point de vue UX. Pourquoi activer le bouton d'édition (ou afficher les détails comme éditables) sur les tâches dont l'utilisateur n'est pas propriétaire? Oui, un homme dans l'attaque du milieu est possible. Mais combien de temps/d'argent êtes-vous prêt à dépenser pour cela (à quel point est-ce critique)?
• En ce qui concerne l'autorisation, demandez-vous à quel point cela fait partie de votre modèle. Ne pas dire que ce n'est pas ou est, juste quelque chose à penser.
• Plus sur la conception globale se trouvent ici: Effective Aggregate Design & Improving performance and scalability with DDD

Answer 2

je le ferais comme ceci:

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