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
Entities are frequently generated. In languages like Java there is no such thing as a partial class, so we cannot extend an entity (not considering patterns like Visitor). So when you need to regenerate your entities, you'll have to add the business logic again, which is not at all practical.
With entities I'd rather go for a high cohesion design between entities and their logic.
Other issues to consider are the fact that not all business operations on an entity are equal in all situations. Also, allowing business logic in entities tends to subject the entity to coupling with integration technologies like XML which, in my opinion, should be kept away from domain logic at all times. In an onion architecture, XML would be in the outer shell and domain objects in the inner, to illustrate how far they really are remove from each other if you want to create a reusable pluggable system.
Beyond the Fowler article mentioned earlier, there is a full treatise on rich vs. anemic domain models in Eric Evans's book Domain Driven Design(2004).
Also, check out http://ffffdcommunity.org/