The business logic is thus baked into the architecture of the program itself, making refactoring and maintenance more difficult and time-consuming.
He says: The fundamental horror of this anti-pattern is that it's so contrary to the basic idea of object-oriented designing; which is to combine data and process together.
The anemic domain model is just a procedural style design, exactly the kind of thing that object bigots like me ... have been fighting since our early days in Smalltalk.
[6]"Certain liabilities the programmer must consider are introduced by using an anemic domain model: An anemic domain model would have one write code like the following (written in C#), which by itself does not implement any of the business concerns, in this case, that a height or a width cannot be zero or negative, or that somewhere else there is a requirement for the area of the rectangle.
This means that those functionalities are implemented somewhere else, no longer on the "business" side of the program, but somewhere else hidden within its architecture.
This allows the program to assume certain attributes are true about objects without implementing validity checks elsewhere within the architecture.