3 ms·
This is actually a part of understanding the specific domain. How do the educational practitioners think about the problem for application your working on? Is t
by UK-AL 9y ago
This is actually a part of understanding the specific domain. How do the educational practitioners think about the problem for application your working on? Is the application student or course centric? This is big part of DDD, and involves working domain experts and getting inside each others heads.
You could defiantly model it as the Register method on the course. But this example shows how you can avoid people messing around with internals once you've modeled it. There is only one way of registering for a course.
- barrkel 9y agoI know there are ways to solve the problem; but I believe these are accidental complexities, not essential complexities. That is, these design solutions complect the problem, sacrificing simplicity for a dubious principle.
- UK-AL 9y agoActually I think this is a major advantage. They are not complexities, they are putting down into code how you think about your application in your head. If your design is some data, which you can mutate however you want to get the job done, you don't really have model of the application. Your business rules can become inconsistent because different developers are implementing different but similar methods in your business logic layer all applying slightly different rules. If the entities themselves enforce these rules, it become a lot less likely.
- mbrock 9y agoI 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 9y agoSee 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 9y ago"students can be registered for course" - This is already implying an order.
- jstimpfle 9y agoThat's wishful thinking.
- UK-AL 9y agoAll 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.
- mbrock 9y agoIf 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 9y agoNothing 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.
- 9y ago