In his seminal paper about this domain model, Martin Fowler defines the anemic domain model as an antipattern, which defies any basic purpose of object-oriented programming. Of course, I cannot disagree with that at all. Nevertheless, this kind of modeling is far too widespread, as it's a kind of quick and dirty way to design an application.

Essentially, in the anemic domain model, each object maps with its real-world counterpart, including fields and relationships. Those are, in a way, kinds of data objects. What's missing in the anemic domain model's objects is the behavior, meaning the specific actions that are logically associated with that particular concept in the real world. Usually, the objects in an anemic domain model have getter and setter methods, and not much more. All of the behavior is codified as part of specific service objects, operating across all of the other data objects through specific methods.

The issue, here, is that the domain model is simply slipping away from object-oriented programming and toward an overengineered procedural model. This could be good enough in simple scenarios and, indeed, is common in Create, Read, Update, and Delete (CRUD) applications over a relational database, where you are, more or less, exposing tables directly as an application, with very limited business logic on top.

If the model is bigger, and it encompasses more complete business logic, this way of modeling starts to show some limits. The data objects become similar, and it's harder to group them and define relationships. The service objects have more and more methods, with growing complexity. You start to gain the cons of both the procedural and object-oriented methods. After all, you have very few (if any) of the pros of object-oriented modeling. DDD aims for the opposite—building rich and expressive object-oriented designs. Let's examine how to start modeling applications on DDD principles.