<p>I would like to know what the pros and cons are for using an Anemic Domain Model (see link below).</p>

<p><a href="http://www.martinfowler.com/bliki/AnemicDomainModel.html" rel="noreferrer" title="Fowler Article">Fowler Article</a></p>

It seems to me that Fowler's main objection is that ADMs are not OO, in the following sense. If one designs a system "from scratch" around passive data structures that are manipulated by other pieces of code, then this certainly smells more like procedural design than object-oriented design.
I suggest that there are at least two forces that can produce this kind of design:
Designers/programmers who still think procedurally being required to work in an object-oriented environment (or assuming that they can...) to produce a
new
system, and
Developers working to put a service-like "face" on a
legacy
system designed in a non-OO fashion (regardless of language).
If, for example, one were building a set of services to expose the functionality of an existing COBOL mainframe application, one might define services and interfaces in terms of a conceptual model that does
not
mirror the internal COBOL data structures. However, if the service maps the new model to the legacy data to use the existing-but-hidden implementation, then the new model might very well be "anemic" in the sense of Fowler's article -- e.g. a set of TransferObject-style definitions and relationships with no real behavior.
This kind of compromise may very well be common for the boundaries at which idealistically-pure OO systems must interact with an existing, non-OO environment.