domain-driven-design - 领域驱动设计：如何正确思考和设计聚合根？

Question

我正在开发一个学校管理系统作为个人项目，并且我正在通过 DDD 方法进行指导。

我现在有这个结构。

public class Teacher : Value object
{
    public Guid ID { get; private set; }
    public Charge Role { get; private set; } // Enum
    public DateTime ActiveFrom { get; private set; }

    // Some logic
}

public class Student : ValueObject
{
    public Guid ID { get; private set; }
    public string FullName { get; private set; }

    // Some logic
}

public class Subject : Entity
{

    private List<Teacher> teachers
    public string name { get; private set; }

    // Some logic like
    public void AddTeacher(Guid TeacherID) { ... }
}

public class Course : Entity, IAggregateRoot
{
    private List<Subject> subjects;
    private List<Student> students;

    
    public void AddSubject(Guid ID) { ... }

    public void AddStudent(Guid ID) { ... }

    public void AddTeacherToSubject(Guid TeacherID, Guid SubjectID)
    {
        var subject = subjects.find(SubjectID);
        subject.AddTeacher(TeacherID);
    }
}

无论进行一些调整，导致我这样做的问题是：

在课程管理的一个聚合根中，我用科目填充我的课程，学生关闭边界上下文但是，将教师添加到科目的逻辑似乎是另一个聚合根（科目聚合根）的一部分，或者它可以是相同的？另一方面，为了管理属于一门课程的不同科目的时间表，我需要访问这个科目列表（示例代码中的那个）：我必须重复这个再次添加科目的逻辑，否则会有不同的方法 ？

最后，我不知道我是否错了，但似乎和实体的逻辑，在这种情况下，课程，它被装箱到不同的地方或聚合根或不同的边界上下文。即一个用于管理，另一个用于计划，另一个用于其他操作。科目或学生、教师等也是如此……这是思考 DDD（聚合根、实体等）的正确方式，还是我正在制作一个大意大利面条代码？

标签： domain-driven-designdata-modeling