[mbrock]

I wonder how to even formulate the question to the practitioners -- it seems like an artificial choice imposed by the computer formalism (single-dispatch OO).

In other words, I don't see how it is a domain question, and it seems likely that the domain practitioners just think "there are courses, and there are students, and students can be registered for courses".

My suspicion is that DDD would basically be better without the focus on single dispatch OO.

[redy]

See my comment below. The language of the business will almost always guide the design in the right direction. There are rare cases where the business is unaware of a more "essential truth." This isn't about OO it's about faithfully capturing the model of the domain which is all DDD is.

[UK-AL]

"students can be registered for course" - This is already implying an order.

[mbrock]

If I say "students can be registered for courses in the school" then you might think the OO model should be

    school.register(student, course)

which does actually seem reasonable to me. Here the school object would basically be the system's logic as a whole, and both the course and the student could just be IDs.

I really think single dispatch OO is a huge distraction and I haven't seen any strong arguments for its use as a general paradigm.

[UK-AL]

Nothing about DDD says you can't use multi-dispatch. If this how you think about the problem. Then this is your solution if your language is capable of expressing it.

[mbrock]

Yeah, I'm quite a big fan of Eric Evans and DDD. Especially the more high level parts about ubiquitous language, bounded contexts, anti-corruption layers, and many of the other patterns. Yet I think that the focus on single-dispatch OO kind of dates the book and makes it less general and beautiful, much like how the GoF's "Design Patterns" book is more banal than Christopher Alexander's work on pattern languages because of the overemphasis on specific implementations of single dispatch OO patterns (the notorious visitor pattern, for example).

[konschubert]

If the pairings of courses and students are registered in the school object, then that's basically OO implementation of a many to many relationship of students and courses.

That's why I like Django. You just tell it that you want a many-to-many between students and courses and it does they for you, symmetrically, without forcing you to introduce a class such as "school".

[UK-AL]

Bi-directional models come with their own problems.

[jstimpfle]

That's wishful thinking.

[UK-AL]

All your trying to do is match their language, so its easier to develop against a description of a use case. Technically either way allows you do what you want to do.