Question

I have the following entities in Entity Framework:

public class School {
    public int Id { get; set; }
    public string SchoolName { get; set; }

    public virtual ICollection<Course> Courses { get; set; }
}

public class Course {
    public int Id { get; set; }
    public int SchoolId { get; set; }
    public string CourseName { get; set; }

    public virtual ICollection<Student> Students { get; set; }
    public virtual School School { get; set; }
}

public class Student {
    public int Id { get; set; }
    public string FullName { get; set; }

    public int Grade { get; set; }

    public int CourseId { get; set; }
    public virtual Course Course { get; set; }
}

• Each school has many courses
• Each course only belongs to one school
• Each course has many students
• Each student only belongs to one course

I have a specific page in my application that needs to summarize some information which you can see in this jsfiddle: http://jsfiddle.net/Jsf3f/

Basically I need to display the data in a table that rolls up the information. I need to show each school in its own line, which has the total number of students in all courses and the highest grade in all of those courses. I also need to display each course individually that also summarizes the information with the number of students enrolled in it and the highest grade of all students in the course.

In order to do this I am pretty sure I need to create new Domain classes that can summarize this information.

My questions:

To properly summarize this information would I create a repository that deals with returning a SchoolSummary object. Would SchoolSummary be considered an aggregate root in Domain Driven Design?

Do I instead try and create a different domain model and have the summary be only a view model that can easily translate the domain objects into summaries.

I think I am having trouble trying to visualize the domain layer vs just my database layer (Entity Framework) and presentation layer (MVC).

Answer 1

Truth be told you can apply DDD in the rest of the app, but in this case you’re dealing only with queryies and reports. If you’re using CQRS (Command Query Responsability Separation) then basically you can create a simplified query model (parts of the view model itself) and a query repository which will serve them.

So no need for AR, just a repository tailored for the reporting usage. About DDD, IMO is suitable just for commands (create and update model), but an app has both reads and writes so what is not a ‘write’ can be handled in a more simplistic way. In the end we apply a mindset where it’s needed in an app, we shouldn’t force an app to fit in a mindset.