To understand DDD better, I am trying to create the Domain Layer of an online class application. I have a concept of a Student, Tutor and Session.

I thought of having one aggregate called Session and they can contain the entities of Student and Tutor.

But I ran into problems with this:

  • The Student and Tutor concepts may have many other related Domain Objects that has nothing to do with the concept of a Session.

  • The client may decide to have courses in which Tutors and Students are assigned, in that case I would need to have the duplicate entities in the Course aggregate.

If I do keep them as separate aggregates, there is a relationship between entities across aggregates, which should not happen.

How can I design this part of the Domain Layer?

  • 3
    You’re falling into the data modeling trap. Model aggregates around behavior. Aggregates ideally only contain data they mutate or that’s needed to make decisions with.
    – Rik D
    Commented Apr 12 at 7:00
  • 1
    @RikD isn't that true for all objects, closures, and functions? Commented Apr 12 at 14:51
  • you have no need for any Aggregates at all. just use the ids to link
    – Ewan
    Commented Apr 12 at 19:24
  • Session should be an iteration of a Course, which in turn has a tutor and a number of enrolled Students. Not sure how this translates into DDD, but one way to represent this is by having a list of Sessions as a field of Course or by having Course as a field of Session, or both. Commented Apr 12 at 19:42
  • 1
    Being pragmatic, DDD is the business rules. The need for aggregates exists in almost every project past the most basic. For example Person is the base for Student and Tutor, etc. So, write up your rules for your fictional school. Design to that. Example: Can a Student be a Tutor? But only in a different topic? Same topic, but at a lower level?
    – DogBoy37
    Commented Apr 14 at 23:48


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.