Talk:Anemic Domain Model

From Wikipedia, the free encyclopedia

The description of this practice should be kept objective. Whether the use of business objects excluding business logic is a good or bad practice is certainly a matter which can be discussed in a Benefits/Liabilities section of the article, but the article should not presume this pattern is in fact an anti-pattern. The term Anemic is intended to be accepted negatively, and as such this entry is really about the pejorative view on this practice. As such, it would be acceptable for this article to evolve into one weighted more heavily toward the beliefs of why this pattern is considered an anti-pattern and another page created to discuss the pattern void of subjective opinions about its inherient worth, but regardless the context should remain objective.

The discussion section is the place to keep the less-than-objective arguments about whether the pattern is indeed an anti-pattern or not.

That said, it should be noted that while Martin Fowler expresses dislike for this pattern, his article does little to point out any actual liabilities apart from his vague statement that they "incur all of the costs of a domain model, without yielding any of the benefits" and expressing a primary cost of "awkwardness of mapping to a database". While I would be interested to hear what he means by this and weigh the liabilities and benefits of the various approaches, my point is that in such a lengthly article he does little to actually detail why the pattern is an anti-pattern. He does point out that this doesn't follow typical object oriented design (which I might tend to agree depending on what sort of domain logic is not being included), but this in-and-of-itself can't be considered a liability unless it has actual practical consequence, in which case the actual consequence is to be listed as the liability.

To elaborate on my point concerning its lack of object oriented nature (that being the encapsulation of data with behavior), depending on what you are modeling will dictate whether the object is actually a true model of the real world or not (which is the goal of pure OO). For example, let's say you want to model a package for a shipping company. A package has weight, height, girth, value, etc. which are inherent properties of a package from the company's point of view. A package can not, however, ship itself, open itself, validate itself, empty itself (well, maybe if it contains a bomb), etc. The point is, if we are going to be OO purists about modeling the real word, let's go all the way with it. On the other hand, if our goals are first and foremost to solve business problems in the best balance between simplicity, efficiency, extensibility, and maintainability, then let's lay the cards out on the table in terms of benefits and liabilities and judge which approach is better for our particular needs. One approach will never be the the "right" approach in all circumstances which I know Martin Fowler would agree with.

I think that having a "benefits and liabilities" is just going to encourage voicing of unsupported opinions. Perhaps a "Theory" section, and a "Criticism" section, mirroring the structure of other articles? Ideally with references. Of course, as you rightly point out, the concept is a little abstract.

For what it's worth, I have been at the sharp end of an ADM, and I can give you my opinion on what's wrong with it, which from my reading tallies strongly with Fowler's.

From my perspective, the true strength of OO is encapsulation. I'd even go so far as to say it's the whole point of OO. Encapsulation encourages modularity, which in turn encourages separation of concerns. Do Every Task Once, In One Place. Obviously, that's an ideal not always achievable.

The problem with an ADM is it turns the DM into a series of structs, and you might as well be writing procedural code (in fact, I'd argue that's exactly what you're doing). I'm not saying modularity is impossible to achieve procedurally, just that the programmers have to show more discipline. If they are sufficiently disciplined, what is the point in maintaining all the syntactical and computational overhead of classes when you don't want to utilise their main advantage?

From real world experience, an ADM in a large system generates exactly the problems you'd expect. The data becomes separated from the code that manipulates it. As the system evolves, the logic that affects the data starts to become scattered across the Service Layer. Attributes are directly manipulated by getters and setters, and as that becomes ingrained as standard practice, decisions about the state of objects begin to be made by examining those attributes. It's the difference between if( account.CanWithdrawCash() ) and if( account.Balance > 0.00 ). If I later introduce the concept of agreed overdrafts, one of these is going to break. If it's a big codebase, chances are it's going to break in a lot of places.

The problems in the system in question were a lot less obvious than that and a lot more insidious  :) Racecondition 10:35, 30 October 2007 (UTC)

Just thinking about it, the Benefits section doesn't convince me. The first point is orthogonal to DM vs ADM. There is nothing about a full DM that prevents separation of concerns into layers, because the DM is supposed to be your business logic layer. There is also nothing I can see about an ADM that makes it easier to do so, either.

For the second point, there exist well known solutions for having multiple behaviours for the same attribute set; see the Strategy pattern. To some degree (depending on your precise requirements) this is also achievable using abstraction and inheritance. I don't see that this is necessarily easier in an ADM. Again, I'd be tempted to say that this is an unrelated issue.Racecondition 06:46, 31 October 2007 (UTC)

Given the title of the article, I think we should stick with documenting the anti-pattern here. It is true that there may be other ways to view the situation, in which case we should document those views as well, partly here, but primarily under articles for those views. Consider Creationism and Evolution, two views on the same phenomena. Each main article is about a particular view, and each references the other, but the articles are separate. William Pietri (talk) 19:33, 8 May 2008 (UTC)