Should Enterprise Java entities be dumb?

Question

In our legacy Java EE application, there are loads of value object (VO) classes which typically contain only getters and setters, maybe equals() and hashC

Answer 1

Right, here's a summary of the feedback I got from my Java EE trainer.

From a pratical point of view, striking a compromise between anemic and rich domain by moving logic shouldn't a problem as long as the methods work with the attributes of the Entity. When it comes to a rich domain, the line has to be drawn somewhere and apparently both Fowler and King have emitted comments in that direction.

For example, consider a calculateInterestRate() method inside a BankAccount that fetches information from other domain objects like verifying how long someone has been a client. To avoid dependency, one could split the method accross objects but this approach means that code can end being strewn accross several classes. At this point, one might as well make a InterestCalculator class.

Another thing to take into account is thread safety. Singleton DAOs and Services handled by Spring should be thread safe whereas anything in the domain model will be exposed to concurrency issues.

Lastly, there's the problem of maintenance. Are you sure you will be around to maintain the application in a couple of year's time? The choices you make may appear to be justified but are you certain that the next developper will have the expertise necessary to easily understand your code?