• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Anti-Pattern: Anemic Domain Model

 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
An interesting article by Martin Fowler: http://martinfowler.com/bliki/AnemicDomainModel.html
 
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Kyle Brown
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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!
 
Ranch Hand
Posts: 1551
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Kyle, thank you very much for the explanation!
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 am displeased. You are no longer allowed to read this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic