Use OOP, of course procedural programming is easier than object-oriented programming, keep in mind that the correct use of OOP is a great remedy against the Anemic Model.Be careful with ORM, they are responsible for creating Domain Objects automatically, producing real containers of public setters and public getters, which leads to an Anemic Model.Think long before you create a Domain Services, they are used as real Silver Bullets by the developers, but end up being the biggest causes of the Anemic Model.Certainly your objects will need some initialization data to maintain a valid state. Avoid constructors without parameters.

Always validate the status of your entities, your Entities must self validate.If your properties are defined by the Client directly you will lose the chance to use Domain Events and you will have to validate your Entities by external methods. Of course this approach leads to many design issues and drawbacks. Usually business logic ends up being implemented in other classes, called Services, that transform the state of the Domain Objects. In Anemic Model the Client is responsible for interpreting the purpose and use of the Domain object. The problem is that most developers seem to think this is completely normal and do not recognize that there is a serious side effect when employed on their systems.

The fundamental horror of this anti-pattern is that itвЂ™s so contrary to the basic idea of object-oriented design which is to combine data and process together.ДЄnemic Domain Models appear everywhere in our industry every day. This model was first described by Martin Fowler, who considers the practice an antipattern. Anemic Model is a Domain Model where Domain Objects contain little or no business logic.

Domain driven design martin fowler