Talk:Anemic domain model

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Software.

Objectivity

The description of this practice should be kept objective. The opinion that the use of business objects excluding business logic is a bad practice is certainly a matter which can be set forth, but the article should not presume this pattern is in fact an anti-pattern.

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.

The benefits/liabilities section follows the Microsoft terminology, but as this is a criticism of a pattern rather than a formal description of a particular pattern the layout is a bit awkward. There should probably be a separate page describing this pattern for which this entire page is the criticism, both pages linking to one another. As the article was initially written, the whole description of the pattern fell into the "Theory" category. —Preceding unsigned comment added by Derekgreer (talk • contribs) 14:00, 27 June 2008 (UTC)[reply]

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.

Code duplication is certainly not encouraged by the Microsoft Three-Layered Service Application architecture or a related concept, component-oriented programming. Just because the behavior is separate from the object model doesn't mean the behavior can't be used by everyone. It just becomes component-oriented or service-oriented. I would also point out that while OO is about encapsulation, it's also about real-world modeling. In the real world, there are often things that are largely non-functional that you have to operate on. So true OO doesn't preclude you from having things be modeled with data entities, it would just argue against modeling things that inherently have behavior as such.

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?

Using data-only entities within an architecture (such as that prescribed by the Microsoft TLSA architecture) does tend to incorporate procedural-style code (in much the same way as SOA does), but foregoing encapsulation in this case is generally done to facilitate greater separation of concerns in other areas. For instance, this design practice can be advantageous in composite applications where a single entity is used throughout a system, but where multiple modules maintain business processes that are otherwise orthogonal to one another. By separating the behavior, each team (and new teams in the future) can offer components which operate on a common entity (e.g. Customer), while maintaining clear separation between their concerns and the concerns of another group. Employing inheritance can solve some issues in this regard, but this technique is not wholly sufficient for all cases.

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.

I can see where this would be a problem if the concern of examining the balance existed in multiple components/services, but I would first look at whether responsibilities were properly allocated to begin with. Can you elaborate on your example?

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)[reply]

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.

In some cases, you may want to give one component access to the data (e.g. a view), but prohibit access to the behavior provided within the "business layer".

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)[reply]

Strategy is about varying the algorithm of like behaviors, not about completely unrelated behaviors. Inheritance can solve some scenarios, but not all. At some point, you start having discussions about acceptable duplication of data in the DM world.

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)[reply]

I thought about this as well, but is there currently an accepted name for non-behavioral models apart from the pejorative one?

Regarding the above comment saying that "the article should not presume this pattern is in fact an anti-pattern", it would be interesting to see some reference to some respected guru (other than Fowler) who disagree with Fowler and claims that it is rather a pattern than an anti-pattern. Though I am a bit skeptic about finding such a referece, since my feeling is that the anemic domain model is very widely considered as an anti-pattern in the object-oriented world. Tomrbj (talk) 19:06, 13 January 2009 (UTC)[reply]

About the name of this anti-pattern in a not pejorative way, it's procedural programming, you group functions into library, function work on data (generally struct). There is reason to use such design: constraint prevent you for using correct OO design (historical reason (like C library used in C++), framework reason etc.) But saying that this anti-pattern may be the appropriate solution in some case so it's not an anti-pattern it's saying that excessive car speed is not a problem since emergency vehicle do that... by design. What's the point? It's an anti-pattern because it's a known problem in software development, some project faces difficulties BECAUSE of this exact pattern. Good encapsulation is the thing to do, thousands of book have been written. Encapsulation is one of the first chapters of any book for learning to develop in Object Oriented. —Preceding unsigned comment added by 76.64.250.152 (talk) 03:09, 25 February 2009 (UTC)[reply]

Agreed. We don't need a separate page to describe the "exceptions to the rule [of not using the ADM pattern]" although we could mention them in a section on this page. Bigwheels16 (talk) 18:33, 15 January 2010 (UTC)[reply]

From my experience ADM can lead to lots of change if not proplerly implemented. A business rule change which is not present at one place and scattered throughout the service layer can be maintanence nightmare. As ORM frameworks like hibernate suggest we should be using more of Rich domain model —Preceding unsigned comment added by 121.243.107.10 (talk) 09:46, 2 September 2010 (UTC)[reply]

ADM is not necessarily procedural. In strictly FP languages such as Haskell and Erlang "separation of behavior and data" is mandatory as OOP does not exist. In this model behaviors can be added easily but new data attributes are more difficult. Also interesting to note that FPs usually employ COW for ADM. —Preceding unsigned comment added by 74.104.146.239 (talk) 12:40, 4 September 2010 (UTC)[reply]

I added a reference in the Benefits section. It may not be the most reliable source but I found both the article and comments to have good discussion. I think it's better than having no reference for Benefits. RVS (talk) 01:17, 20 March 2015 (UTC)[reply]

The premise of a Domain model based architecture is object orientation. Agree that this is not the only approach, but an Anemic domain model is an anti-pattern in the context of the Domain Model pattern. Calling into question the Domain model pattern in general is fine, but this is not the context to do it in. Doing it here steers away from using OO principals in a domain model, which the premise of and vital to a domain model. A Domain model is OO by definition, domain model without OO is some other pattern. — Preceding unsigned comment added by Rickbadertscher (talk • contribs) 18:44, 12 February 2018 (UTC)[reply]

POV is Incomplete

The article incorrectly assumes a false choice between imperative and OO. There is no mention of functional programming, which can easily address most or all of the cons listed for separating business logic from data structures. In functional programming, OO itself is considered an anti-pattern. 173.14.140.254 (talk) 13:10, 17 August 2013 (UTC)[reply]

Questionable objectivity and accuracy in Benefits section

=* Works well with simple applications:

   This is not objective, it may or it may not depending on many factors.

Avoids the need for a complex OO-Database mapping layer:

   This is not true as the utility of an OO-mapping layer this is not a function of the amount of behavior in the domain model but a function of wether inheritance relationships exist amongst the model types.   Also even with a rich domain model, a complex OO mapping layer is not a absolute requirement.  Also, the mapping layer being "complex" is subjective.

More compatibility with mapping and injection frameworks expecting dumb properties rather than a specific constructor or property population order. [4]:

   This statement is not clear, possibly cite an example.

Clear separation between logic and data[4].

   This exact bullet point should be in the Liabilities section also, as it perfectly subjective.     That is the entire premise of Anemic domain model being an anti-pattern.   Is this a tenant principle in functional programming?  As it is the inverse of the tenant principle of OO programming.  — Preceding unsigned comment added by Rickbadertscher (talk • contribs) 18:31, 12 February 2018 (UTC)[reply]