4 ms·

There are well-defined patterns for such behavior. Domain services are introduced to protect invariants _between_ entities. Implementation is simple really. Stu

There are well-defined patterns for such behavior. Domain services are introduced to protect invariants _between_ entities. Implementation is simple really. Student “fills out course registration form” (VO) and then Course “completes registration with filled out registration form”. Essentially the behavior of registering for the course is distributed between Student and Course as appropriate. The point I’m trying to make is that the problem is not inherit in OOP. The problem is that domain modeling is hard. If a developer cannot synthesize the above “solution”, I’m not sure a different paradigm is going to help.

jdmichal 7y ago
And why does a Course register a student? Why does it know what a "course registration form" is? None of these things have anything to do with the Course object or is invariants... The Course is just one of many parameters into the workflow. Why is it therefore responsible for the actual act of registration? In real life, the aptly named "student registrar" is responsible for performing the task. But they're not an entity within this system... Rather they are the context in which this system is running. So a non-bound function actually makes perfect sense... It's bound to the top-level registrar context of the system. In BPMN, the registrar would be one swimlane, and the registration the process, with additional swimlanes for other actors like the student. The registrar still owns the process, but BPMN allows for other actors to also play parts within the system. A relational view would introduce a Registration which would join a Course and Students. The workflow would create a Registration, which defacto means that an individual Registration cannot be responsible for executing this.