3

I have a question about an issue I always seem to run into when building a domain model. The issue comes up whenever a domain object is used in what I am calling an "offering" scenario and in a "usage" scenario. For example, let's take a small school.

This school offers programs of study. Each program requires that a student enroll in and complete a certain number of classess of a certain type. In other words, one program may require 2 "general education" type classess, and one "math" type coruse. Here is the domain model for this:

Program Offering Domain Model

This is all fine so far. Now, let's consider the student enrolling in this program. The student has the option to select from 2 "general education" classess and one "math" class. Once these classes are selected they need to be associated with the program the student is enrolled in. Here is a domain model for this:

Student Enrolled in Classes

Both of these domain models seem fine. However, when you add them together you get something that is not clear at all. You get the following:

enter image description here

This is confusing because you cannot tell what relationships apply to which scenario (the "offering" or the "usage", in other words, the offered programs and the ones that a student has enrolled in). It looks like programs that the school offers might already have selected classes. Alternatively you might think that even after a student is enrolled in a class there are still class options.

Is there a general way to deal with this issue? I find that it presents itself in most businesses and therefore software projects. Are there domain modeling "patterns" for things like this?

Thanks for any help that can be provided.

Improve this question
0

2 Answers 2

Reset to default
2

Actually, you discovered what Fowler would probably call a Bounded Context - the idea of splitting one domain model into two different sub-models, one for the "class options" and one for the students' choices.

Just take your third model as a blueprint for your database schema, and keep the other two models as part of the spec. Or try to draw some fences around your objects like this:

enter image description here

Improve this answer
2
  • Thank you! Not sure how I missed that. Now I know what to study further.
    – wmatic
    Commented Feb 24, 2015 at 22:52
  • For further reading, Eric Evans's book spends a number of chapters on Bounded Contexts and how to implement and integrate them in a large team.
    – Benjamin Hodgson
    Commented Feb 25, 2015 at 21:19
2

In addition to what Doc Brown mentioned regarding Bounded Contexts, you might want to consider that you're colluding two different events regarding the student. They enroll in a program, but the selection of a class does not flow through the program itself. That is, You have a ProgramEnrollment for a Student and there is a separate concept of a ClassEnrollment for the Student. The Program defines a set of required courses or categories of courses that the student can select from but the enrollment is separate from the program itself.

Improve this answer
3
  • A very good point, and in reality that is what I ended up doing. I just wanted to illustrate the problem. Thanks for your input!
    – wmatic
    Commented Feb 24, 2015 at 22:53
  • @wmatic - And you'll need to be able to show the student passed the class with a suitable grade and didn't just enroll in it.
    – JeffO
    Commented Feb 24, 2015 at 23:17
  • As I was reading the problem I was coming to this solution, in fact... Really there are two missing classes there: I thought about htese names: StudentProgramSelection and StudentClassSelecion (or ProgramEnrollment and ClassEnrollment as Michael Brown said).
    – Xavi Montero
    Commented Apr 4, 2016 at 0:16

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.