Anemic domain model

Anemic domain model is the use of a software domain model where the domain objects contain little or no business logic (validations, calculations, business rules etc.).
Overview.
This pattern was first described by Martin Fowler, who considers the practice an anti-pattern. He says:
In an anemic domain design, business logic is typically implemented in separate classes which transform the state of the domain objects. Fowler calls such external classes "transaction scripts". This pattern is a common approach in Java applications, possibly encouraged by technologies such as early versions of EJB's Entity Beans, as well as in .NET applications following the Three-Layered Services Application architecture where such objects fall into the category of "Business Entities" (although Business Entities can also contain behavior).
Fowler describes the transaction script pattern thus:
In his book "Patterns of Enterprise Application Architecture", Fowler noted that the transaction script pattern is OK for many simple business applications, and obviates a complex OO-database mapping layer.
Reasons why this may occur
AnemicDomainModel may occur in systems that are influenced from Service-Oriented Architectures, where behaviour does not or tends to not travel.
Architectures like COM+ and Remoting allow behaviour, but increasingly the web has favoured disconnected and stateless architectures.
Criticism.
There is some criticism as to whether this software design pattern should be considered an anti-pattern, since many see also benefits in it, for example:
Example.
Anemic
class Box
Non-anemic
class Box
 public Box(int height, int width)
 if (height <= 0) {
 throw new ArgumentOutOfRangeException(nameof(height));
 if (width <= 0) {
 throw new ArgumentOutOfRangeException(nameof(width));
 Height = height;
 Width = width;
 public int Area()
 return Height * Width;