A note on anemic antipattern

In the object oriented principles POJOs or java objects represent data.Some people do write business logic along with the data objects.The objects do represent the real world object as it is named according to business nouns.The anemic anti-pattern describe the use of a domain model where the business logic is implemented outside the domain objects. The antipatterns help us to understand what are bad practices.These pitfalls are to be avoided.There is a fundamental mismatch with the OOP concepts explained by Martin Fowler in his article . With this pattern, logic is typically implemented in separate classes which transform the state of the domain objects. Fowler calls such external classes transaction scripts.It decouples the binding using a separate business layer to contain the logic.When we use hibernate-like persistance layer, most of the objects are basically attribute beans.The businesss logic will reside in a layer in which the process is spread between these objects.A service layer on top of domain layer or models is used when domain model impelementing multiple interfaces for data storage and logic.The service layer is not supposed to serve as a business logic provider/container, but rather as an access / synchronization layer, to allow for radically different interfaces access to your domain model.Ideally, the domain object would contain behavior to handle its own persistence. If domain objects offered such behavior, then the service object could deal directly with the domain object in a very object-oriented way. Instead of telling a DAO to persist a customer, the service would tell the customer to persist itself. There will still be a DAO, but the domain object will do its own dealing with the DAO, unbeknownst to the service object. In effect, the domain object and the DAO swap positions with relation to the service object.The attributes are provided by POJOs and the behaviours are provided by service layer. These forms the basis of domain driven design.I believe that in Anemic Domain Model the behavior is implemented in separate classes increasing the lines-of-code in the application layer and it also makes the application code less maintainable since the use of domain objects is no more logical.But the loosely coupled nature could provide more benefits of relationsgips,encapsulation,simplicity,readable,more functional support and so on.These are mere analysis in my perspective, hope I could add much more knowledge about this in future.