I think we have an anemic Domain Model

I have been pouring over the latest Fusion Authority Quarterly Update, and particularly liked Sean Cornfield's article "Beans and DAOs and Gateways, Oh My!" I am pretty familiar with the four application layers he describes, but have had difficulty at times reconciling all the diverse ways I see those implemented. (design patterns) I feel I have a good grasp on OOP, but most of my current application is still on a version of Fusebox 4 which was modified to the point of not being easily upgradeable. We have tried to do new development in MachII, but my exposure has been modest.With the semi-recent exodus of most of our Java programming team here at work, I have been thrust into the maintenance of a number of Java application. Many of them were authored by different people, but most of them are web services dealing with translation of XML through the marshalling and un-marshalling capabilities of the JAXB libraries. Coding in Java has both been frustrating and eye-opening at times. I simultaneously made the switch from ColdFusion Studio to Eclipse, as well as figuring out our CVS source control server. My first eye-opener was how far the Java world took the whole "EVERYTHING is an object" mindset. I mean not only are basic data types objects with built-in methods, etc but even basic concepts that I would usually represent in CF as a string or Array is an object. In fact, it seems that methods rarely even use strings or ints as input parameters-they always seem to take objects. I digress. I started writing to point out that after reading Sean's article I think I have identified the design pattern I am most commonly seeing in the Java applications I have inherited. He refers to it as the anemic Domain Model. This is a model where most of your business objects have no actual business logic inside them. Instead, they are basically empty shells; mere containers for data with nothing more than getters and setters. All the "real" logic that accomplishes what needs to be done exists in Service or Manager Objects in a surprisingly procedural way. In fact, at times the sheer number of objects seem to only add unnecessary layers of complexity to what should otherwise be seen as a simple objective. In case you haven't read the article, or didn't guess from the name, the "anemic Domain Model" is not encouraged as good practice. So herein lies my current love-hate struggle with Object Oriented Design. It makes sense on paper and in the basic little "cutesy" examples found in books (This is a Apple object with a color property which inherits from the Fruit Class) but it always seems hard to find good real life examples that don't leave me feeling like boiler-plate code must have been on sale that week. I mean, one of the OOP goals is supposed to make code better organized and easier to maintain, but heck-sometimes I wonder when I have to thumb through 97 anemic objects to get to the small mouthful of meat at the bottom of the stack.