提供されているScenerio内でDDD集約ルートを選択するのに役立ちますか？

Question

私はDDDをかなり新しくしています。もし私が知識が不足しているなら、そのような概念についてのいくつかの記事を読んでください。私は、この例を集約ルーツでモデル化する方法について興味があります。

基本は：従業員、会議、およびコメントがあります。各従業員は、コメントを作成できるミーティングに参加することができます。コメントは従業員と会議に従って追跡されます。すべての会議と従業員には一意の識別子があります。

従業員に関係なく、会議からのすべてのコメントを表示する場合は、最初にその会議に属するすべての従業員を取得してから会議IDに一致するコメントのみを並べ替える必要がありますか？

私の従業員のリストが必要な場合、私は確かにそれを得るために会議を通過する必要はありませんので、会議は私の総ルートにすることはできません。おそらくそれぞれが集約ルートですが、Commentsは実際にEmployeeの外では意味をなさないでしょう。私はこのシナリオにどのようにより良くアプローチするかについてのアイデアを探しています。

// Datebase tables 
Meeting 
Employee 
Comment - Contain EmployeeId and MeetingId 


public class Employee 
{ 
    public List<Comment> Comments { get; set; } 
} 

public class Meeting 
{ 
    public List<Employees> Employees { get; set; } 
} 

ご協力いただきありがとうございます。

Answer 1

としてこれを設計します。

コメントは、会議のプロパティにすることができます。私は、会議に関係なく、従業員からコメントを取得することは役に立たないと思いますか？私はあなたがその 'コンテキスト'（==ミーティング）を知らないとき、コメントが意味を持たないとは思わない？

このようにすることで、クラスモデルはChris Marisicの提案と非常によく似たものになります。

これらのクラスの隣に、あなたは以下のリポジトリを持つことができます：

public class EmployeeRepository 
{ 
    public IList<Employee> GetAll() {} 
} 

public class MeetingRepository 
{ 
    public IList<Meeting> GetAll(){} 

    public IList<Meeting> GetMeetingsAttendedByEmployee(Employee emp){} 
} 

Answer 2

私はおそらく従業員とミーティングがあなたの集計のルーツであり、あなたがあなたの集計根のためのリポジトリを作成する必要があります

public class Comment 
{ 
    public string Message {get;set;} 
    public Employee {get;set;} 
    public Meeting {get;set;} 
} 

public class Employee 
{ 
    //public List<Comment> Comments { get; set; } <- why does this matter? 
} 

public class Meeting 
{ 
    //public List<Employee> Employees { get; set; } <- why does this matter? 
    public List<Comment> Comments { get; set; } 
}