UML class diagram with domain and business classes

Question

When we ask to draw class diagrams most of the examples identify the domain classes of the system and show the relationship among them. But it also shows business methods inside those domain classes. Normally domain classes act as DTOs in the application and should be only have fields and the getter and setters know.

For example Doctor is a domain class. If so we can't have the method createPrescription() right? That method should be in some other business impl class which use the domain class Doctor right?

Check below link for a class diagram drawn.

http://umldiagramtutorial.blogspot.com/2012/10/hospital-management-system-class-diagram.html

What i am saying is the Doctor domain class should not have those method instead they should be in DoctorMgtImpl class. Is it correct?

Answer 1

I agree with @vainolo, your question is only related to the implementation. I contibuted to a project whose entities were very similar to this hospital management system. You can see the main entities we used and we didn't put all the DTOs,DAOs in the top-level class diagram. Regarding the implementation, the architecture we adopted was: persistent domain model classes (ex Doctor.java), DAOs to handle those persistent classes with coder-friendly CRUD operations, a stateless business layer ("managers") using the DAOs with interfaces and implementations, controlers using the managers. It would have taken days to model all these classes. We decided the purpose of your UML class diagrams was not to represent the code. I recommend this way to do :)

Answer 2

This is more of a design/OOP question than a UML question. If you adhere to the SOLID principles, your point is correct: they are giving different responsibilities to one object (the doctor). Furthermore, the Doctor is not an abstraction but very concrete thing.

On the other hand, this class model gives you a high-level overview of what are the entities active in the system, what are their functions and how they interact. This diagram can then implemented using different classes (using MVC, adding interfaces, etc). The UML diagram is the initial point of the implementation, but the implementation doesn't (and most of the time) shouldn't be exactly as shown in the diagram (because then why implement at all? just generate from the diagram).