## Metadata * URL:: https://martinfowler.com/bliki/AnemicDomainModel.html * Author:: [[Martin Fowler]] * Publisher:: martinfowler.com * Published Date:: [[2003-11-25]] * Tags:: ## Highlights * The fundamental horror of this anti-pattern is that it's so contrary to the basic idea of object-oriented design; * The anemic domain model is really just a procedural style design, * In essence the problem with anemic domain models is that they incur all of the costs of a domain model, without yielding any of the benefits. * As I discussed in P of EAA, Domain Models aren't always the best tool. * The logic that should be in a domain object is domain logic - validations, calculations, business rules - whatever you like to call it. * One source of confusion in all this is that many OO experts do recommend putting a layer of procedural services on top of a domain model, to form a Service Layer. But this isn't an argument to make the domain model void of behavior, indeed service layer advocates use a service layer in conjunction with a behaviorally rich domain model. * This layer is kept thin. * It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. * The key point here is that the Service Layer is thin * Now, the more common mistake is to give up too easily on fitting the behavior into an appropriate object, gradually slipping toward procedural programming.