File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes OO, Patterns, UML and Refactoring and the fly likes Anti-Pattern: Anemic Domain Model Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Anti-Pattern: Anemic Domain Model " Watch "Anti-Pattern: Anemic Domain Model " New topic
Author

Anti-Pattern: Anemic Domain Model

Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
An interesting article by Martin Fowler: http://martinfowler.com/bliki/AnemicDomainModel.html


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Martin's right on target again as usual. The problem is (as I was quoted as saying at SD West earlier this year) that most people wouldn't know a domain object if it bit them in the butt...
Why? There are several reasons, starting with the fact that few people are actually taught to LOOK for domain objects, because they're never really taught OO design. Instead, people hear something about this "MVC stuff" and begin designing and coding at the "V" and the "C" and never quite get around to figuring out why that whole "M" thing matters.... The issue here is that this style of coding CAN produce working programs -- but not the best-factored ones.
Instead, consider what happens when you apply test-first design, and when you begin with the "code the model first" directive. Here, you often can find a domain model begin to emerge, as you're removed from the exigencies of a particular set of Views and Controllers. However, as Martin points out, if you apply the Application Layer or Session Facade pattern too early in this process, the Session Facade itself can become a "God Object" and render the point moot as well.
Just some observations...
Kyle


Kyle Brown, Author of Persistence in the Enterprise and Enterprise Java Programming with IBM Websphere, 2nd Edition
See my homepage at http://www.kyle-brown.com/ for other WebSphere information.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
This (anti)pattern seems very common where people focus on being stateless. The domain layer does nothing but represent data structures or database tables. This is precisely what MS advised us to do in their DNA architecture. It made sense in a way - it was hardly practical to build up a rich graph of domain objects from the database, execute one transaction against them and then persist them all again.
We've just built a system to a vendor architecture that has no-behavior data objects and all-behavior service layers. It might be ok on the stateless back-end, but the back-end delivers data-only objects to the fat client, which then winds up with very bad OO juju.
How do -you- work with a rich domain object model in web apps?


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
It's simple -- the state has to end up somewhere. Some acceptable places are (in my order of preference)
(1) The HttpSession (as long as the per-person state is not both large AND long-lived).
(2) Very fast persistent domain objects using something like a highly optimized CMP layer, Oracle's TopLink, or an OODB.
(3) Stateful Session beans that act as roots into a richer domain model.
You can't make all applications stateless -- it's like trying to squeeze a bag-ful of water -- it ends up coming out somewhere.
Kyle
Gavin Bong
Ranch Hand

Joined: Apr 25, 2003
Posts: 56
Kyle,
Thus entity beans are domain objects ? Although I find that in most of the work that we do; the business logic is in the SLSB layer and the entity beans end up as proprietary POJOs.
Has anyone read Domain Driven Design by Eric Evans ?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Gavin Bong:
Has anyone read Domain Driven Design by Eric Evans ?

Not yet. But I have seen it been recommended by a bunch of people I trust.
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Originally posted by Gavin Bong:
Kyle,
Thus entity beans are domain objects ? Although I find that in most of the work that we do; the business logic is in the SLSB layer and the entity beans end up as proprietary POJOs.
Has anyone read Domain Driven Design by Eric Evans ?


In EJB 2.0, yes, CMP Entity beans can be Domain objects. Doesn't happen all the time, but it can work out well at times. In fact, believe it or not, Eric Evans (of Domain Driven Design, which I have read and HEARTILY recommend) and I have submitted a proposal to do a JavaOne talk on where domain design fits in J2EE.
Kyle
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Kyle Brown:

In EJB 2.0, yes, CMP Entity beans can be Domain objects. Doesn't happen all the time, but it can work out well at times.

Please forgive my ignorance regarding EJBs - but can you shortly explain *when* Entity beans (don't) make good Domain Objects and in which way this is bound to EJB 2.0? Thanks!
Rufus BugleWeed
Ranch Hand

Joined: Feb 22, 2002
Posts: 1551
I am wondering how Fowler's article differs from Craig Larman's discussion of the bloated controller -
p. 242, Applying UML and Patterns 2nd Ed, Prentice Hall

Poorly designed, a controller class will have low cohesion - unfocused and handling too many areas of responsibility; this is called a bloated controller. Signs of bloating include:
1) There is only a single controller class recieving all system events...
2) The controller itself performs many of the tasks necessary to fulfill the system event, without delegating the work. This ususally involves a violation of the Information Expert and High Cohesion
3) A controller has many attributes, and maintains significant information about a system or a domain, which should have been distributed to other objects, or duplicates information found elsewhere.

My second question is - Does a session bean correlate to what Fowler calls a transaction script? Consider for example when Monson-Haefel implements bookPassage in the TravelAgent.
the entity beans end up as proprietary POJOs.

They are not proprietary. They may be domain centric. But entity beans are conforming to a quasi-open standard. no? Concurrency control, persistence, security and a transaction model are hard to create with a roll your own pojo.
[ December 03, 2003: Message edited by: Rufus BugleWeed ]
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Originally posted by Ilja Preuss:

Please forgive my ignorance regarding EJBs - but can you shortly explain *when* Entity beans (don't) make good Domain Objects and in which way this is bound to EJB 2.0? Thanks!


Sure, Ilja. Prior to EJB 2.0 Entity EJB's could not have relationships. Thus it wasn't possible (at least in a vendor independent way) to declare that a Person had an Address, or that an Order had OrderLineItems. That was addressed in the EJB 2.0 spec, and thus many OO designs could then be represented in Entity beans.
The problem is that inheritance is still ill-defined in Entity beans. Some vendors (notably WebSphere) support inheritance in a reasonable way, but others do not support it at all. That makes certain design decisions very tough to deal with -- you end up doing lots of delegation, or duplicating code, which makes things cumbersome.
So, the range of design options you have is wider now in EJB 2.0, but it still doesn't have the full range of options available to someone using POJO's. That's the short version (the long version could take a few dozen pages...)
Kyle
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Kyle, thank you very much for the explanation!
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I am wondering how Fowler's article differs from Craig Larman's discussion of the bloated controller

One implementatoin of the anemic domain model anti-pattern is to make domain objects that really just represent database tables with no behavior, and then build a "verb" object for every businessy transaction you do: AddItemToCart, ValidateCreditCard, ConfirmShipping, etc. (These sound a lot lke "transaction scripts" to me, but I'm not sure they match Larman's or Fowler's definition.) You could wind up with many small transaction objects. Is this necessarily evil? It's not an intellectually pleasing rich object model, but it works.
I'd guess a "bloated controller" at this level results when you put all your transactions into one controller.
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Yup -- and I've been guilty of doing (and even suggesting to others) the exact same thing -- but mostly back in the EJB 1.1 days prior to real Entity bean relationships.
I'd consider this a class of "Transaction Script" in Fowler's terms.
Kyle
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Anti-Pattern: Anemic Domain Model