Anaemic Domain Model
Objects that hold data with no behaviour, leaving business rules scattered across service classes where they are duplicated and inconsistently applied.
The pattern is so common it is often mistaken for good design: entities are data structures with accessors, and all logic lives in service classes that manipulate them from outside.
The cost is that invariants have no home. A rule such as "an order cannot be cancelled after dispatch" exists wherever someone remembered to check it, which means three of the four code paths enforce it and the fourth does not. The bug is not in any one place; it is in the absence of a place.
The alternative puts behaviour with the data it governs: the order object exposes a cancel operation that enforces the rule and refuses invalid transitions, and there is no way to set the status field directly. The invariant is now impossible to violate rather than conventionally respected.
The nuance worth stating, since this is often argued as an absolute: anaemic models are entirely appropriate for genuine CRUD — a reference data table, a configuration store, a simple form application. The cost only appears where there are real business rules, and applying rich domain modelling to a system with none is its own form of over-engineering.
The diagnostic that separates the two cases: are there rules about what states are valid and what transitions are permitted? If yes, they belong inside the model. If the entity is genuinely a bag of fields the user edits, it is not anaemic — it is simple, correctly.