Comparison
Anaemic domain modelvsDomain model
Anaemic domain model
the objects have only fields and accessors, and every rule about them lives in a class ending in Service.
A model that looks object-oriented — a class per concept, carefully named — but holds no behaviour, with all the logic in separate service classes. Fowler named it an anti-pattern because it pays the full cost of the mapping and gets none of the benefit: the data and the rules that protect it are apart, so nothing can enforce an invariant. The honest counter-argument is that for a thin application it is simply a transaction script with more files, and the mistake is claiming it is a domain model.
Full entry →Domain model
the rule about when an order can be cancelled lives on the order, and there is exactly one copy of it.
An object model of the business in which the objects carry both the data and the rules that operate on it. It pays off when the rules are genuinely complicated and interlocking, because each rule has one home and the model can be tested without any infrastructure. It costs more than a transaction script up front and is the wrong choice for an application whose logic is mostly validation and storage.
Full entry →