Employee persistence question
Regarding the persistence question with the Employee class as an example. I think this is a really bad example for the purpose of discussing domain model design as it's clearly not been taken from a proven design. In my experience you can only have a useful discussion based on a proven design.
For example, is it the responsibility of the fire() method on the Employee class to clean the employee's desk? It's hard to be sure, but Employee is probably an Aggregate and Desk an immutable Value Object. I don't see what functionality would be implemented in the clean() method of the Desk class. A more useful thing to do in the fire() method to me seems to set the desk member variable to null. So the fire() method looks like this:
Code:class Employee{ public void fire(){ setDesk(null); setStatus(FIRED); setSalary(0); setFiredDate(new Date()); } }
What's the impact on persistence? If you use Hibernate the relationship between Employee and Desk will be automatically removed.
A comment on the exact role of the Desk class. First I talk about Desk as a Value Object, next I say it's managed by Hibernate as an Entity. Which one will it be? In this use case Desk clearly is a Value Object for Employee, and probably for the entire application. It's not the role of an HR application to manages desks in a database. Even if the HR application does manage desks, this should be implement as a separate module using it's own domain model. In this case you can implement the Desk class as a value object yet configure the class as an Entity in Hibernate.
How to call the fire() method when the FIRE! button is clicked in the web browser? First of all, the Employee that is being viewed should be loaded in the HTTP session (or flow scope is you use Spring Web Flow) to enable Optimistic Locking.
In the controller I would call a EmployeeManager.fire() method. The method looks like this:
It makes a lot of sense to me to keep the persistence details out of the domain model in this case, I see no reason why the Employee class should be responsible for updating its state in the database.Code:public class EmployeeManager { /* setter ommitted */ public void fire(Employee employee) { employee.fire(); employeeOrmRepository.attach(employee); } }
Why? Well, I guess there's only one place in the application where an Employee can be fired, for example the Employee detail screen.
Does this answer all questions about persistence and domain models? No. Do we need a catalog of domain models used in real applications for educational purposes? Yes.
Reply With Quote
Originally Posted by josenyimi
... But in a pure object oriented way you are right, of course.
