I would like to know what the pros and cons are for using an Anemic Domain Model (see link below).
+3
A:
It seems to me that Fowler's main objection is that ADMs are not OO, in the following sense. If one designs a system "from scratch" around passive data structures that are manipulated by other pieces of code, then this certainly smells more like procedural design than object-oriented design.
I suggest that there are at least two forces that can produce this kind of design:
Designers/programmers who still think procedurally being required to work in an object-oriented environment (or assuming that they can...) to produce a new system, and
Developers working to put a service-like "face" on a legacy system designed in a non-OO fashion (regardless of language).
If, for example, one were building a set of services to expose the functionality of an existing COBOL mainframe application, one might define services and interfaces in terms of a conceptual model that does not mirror the internal COBOL data structures. However, if the service maps the new model to the legacy data to use the existing-but-hidden implementation, then the new model might very well be "anemic" in the sense of Fowler's article -- e.g. a set of TransferObject-style definitions and relationships with no real behavior.
This kind of compromise may very well be common for the boundaries at which idealistically-pure OO systems must interact with an existing, non-OO environment.
joel.neely
2008-11-03 14:01:29
A:
An anemic domain model is an anti-pattern. Anti-patterns don't have pros.
andreas buykx
2008-11-06 20:54:54
I disagree. Most Antipatterns have corner cases in which they are a better solution than other alternatives.
Bill Karwin
2009-11-05 16:18:02
Anti-patterns do have pros. That's why people use them, even though they are usually bad ideas.
Kristopher Johnson
2009-12-08 00:16:39
+7
A:
The pros:
- You can claim it's a domain model and brag to your developer friends and put it on your resume.
- It's easy to generate automagically from database tables.
- It maps to Data Transfer Objects surprisingly well.
The cons:
- Your domain logic exists somewhere else, probably in a class full of class(static) methods. Or your GUI code. Or in multiple places, all with conflicting logic.
- It's an anti-pattern, so other developers will ask if you understand the concepts of object oriented design.
Terry Wilcox
2008-11-07 19:15:25
+1 The point about generating the code from database tables is very important for some people. If you're in a rapid-prototyping mode of development, automatic code generation is extremely helpful. We don't pretend this is proper OO design, and putting things together in a sloppy way produces "technical debt." Nevertheless, in many projects time-to-market is a higher priority.
Bill Karwin
2009-11-05 16:22:25
+1
A:
"It's an anti-pattern, so other developers will ask if you understand the concepts of object oriented design."
"An anemic domain model is an anti-pattern. Anti-patterns don't have pros."
Whether the anemic domain model is an anti-pattern is a matter of opinion. Martin Fowler says it is, a number of developers who know OO inside out say it isn't. Stating opinion as fact is rarely helpful.
An, even if it was universally accepted to be an anti-pattern, the chances are it would still have some (though relatively little) upside.
... which are? I am not trying to trick you or anybody, but I'm really curious abou the pros. The cons have been mentioned a thousand times, but I am still seeking resilient pros of the ADM (aside from polemic phrases).
struppi
2009-09-08 21:30:31
A:
"Developers working to put a service-like "face" on a legacy system designed in a non-OO fashion (regardless of language)."
If you think of many LOB applications, these legacy systems will often not use the same domain model as you do. The Anemic Domain Model solves this with the use of business logic in service classes. You could put all this interface code inside your model (in the traditional OO sense) - but you typically end up losing modularity.