0

依存オブジェクトを集約ルートとしてモデル化する必要があるかどうか疑問に思います。私が a を持っていてTaskList、このリストにTasks があるとしましょう。はなしTaskでは存在できませんが、TaskList個別に表示および編集できます。タスクが変更または追加されたときにチェックできる特別な条件はありませんTaskList。これが集約ルートの主な理由になると思います。唯一の条件は、TaskListとそのタスクを所有者のみが編集できることです。TaskListに所有者がいて、TaskList を介してのみ Task を編集できる場合、この状態を確保するのは簡単です。それ以外の場合は、所有者をtransetivlyに検出するか、所有者フィールドをタスクに追加する必要があります。

では、ここでは何が適切ですか？

  • Task と TaskList は両方とも集約ルートであり、それぞれに所有者フィールドがあります
  • 集約ルートとして TaskList のみ、従属エンティティとして Tasks

私は何か重要なものを見逃していますか？

4

2 に答える 2

1
  • 両方を支配する不変条件がない場合は、それらを別々の集計として設計します。
  • tasklist はタスクのファクトリであり、タスクの所有者が誰であるかをタスクに伝えることができます。タスクの後続の動作は、適切な所有者によって実行されたことを確認できます (つまり、タスクは、リストが所有者に伝えた内容を記憶する必要があります)。ただし、これは UX の観点からは貧弱な設計のように見えます。ユーザーが所有者ではないタスクの編集ボタンを有効にする (または詳細を編集可能として表示する) のはなぜですか? はい、中間者攻撃は可能です。しかし、そのためにどれだけの時間/お金を費やすつもりですか (それはどれほど重要ですか)?
  • 承認に関しては、それがモデルの一部であるかどうかを質問してください。そうではない、またはそうであると言っているのではなく、考えるべきことです。
  • 集計設計の詳細については、こちらを参照してください: 効果的な集計設計& DDD によるパフォーマンスとスケーラビリティの向上
于 2011-11-03T10:28:54.867 に答える
0

私は次のようにします：

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-09T14:50:12.620 に答える