What if what you’re modeling really is anemic?

I firmly agree with Domain-Driven Design, but a few weeks ago I looked back at my last several projects and thought that I may not have been adhering to it. Martin Fowler wrote about an anti-pattern called AnemicDomainModel on this page quite a while back. Looking at the last few applications I have written for this client, I basically see a whole lot of bean-like objects, that is objects with a lot of state (getters/setters) but no behavior – a big indicator of the AnemicDomainModel. How could I have fallen into this trap? I struggled for quite a while trying to decide where I screwed up and what precipitated this issue. Have I worked at a high level for too long and forgotten how to take care of the details? Have I been doing too many WebSphere installations and integration setups to do the software development? After thinking about it for a while I finally settled on the opinion that what I’ve been modeling for the last few projects really is anemic, at least from the software design/class modeling perspective, so I can dig my head out of the sand.

You see, I have been working with a client helping build their application infrastructure in WebSphere Portal for a pretty long time. In this particular client’s case the mantra ‘The portal is the glass’, which is basically saying the business logic exists in several other applications and the portal is used to aggregate the content or user interfaces, has held true. Most of the applications I’ve written for them lately are applications that do little more than one of the following:

  • Execute transactions on the company’s legacy mainframe application with information entered on the UI and display some information on the screen
  • Execute RPG transactions on the company’s legacy ERP system with information entered on the UI and display some information on the screen
  • Execute simple CRUD operations against one or more databases and display some information on the screen

There was almost no logic involved outside of validating UI input. Almost everything from a logic perspective was encapsulated into the legacy systems or database queries: pricing, searches, margin calculations, etc. What’s an object modeler to do? The basic pattern that all of the applications followed, since we’re using the Struts portlet framework (MVC), was to have Struts actions that call ‘brokers’ or DAOs, which managed interaction with the external systems (Legacy or database). The brokers or DAOs return one or more of these model objects, which are little more than Java beans used to transport data from the external systems, back to the action objects and subsequently the UI for presentation. Sure, there’s the occasional meat in the objects, but not a whole lot. Lets just say it was a long way from writing an insurance rating engine.

Its definitely AnemicDomainModel from the perspective expecting to see behavior in the model objects, but in this case it serves to actually model the problem domain that it is intended to represent. If you have an application that is simply going to do some CRUD-ish operations while deferring the ‘logic’ somewhere else, you may face this seemingly demoralizing issue too (especially if you are itching to design hardcore OO model). Its not really a problem with your model… its just not an overly exciting domain to model.

Hopefully this post will set your mind at ease that its not ‘model anemia’ creeping in… or maybe I’ll get flamed based in this post and will realize I need to read Domain-Driven Design again… either way, I feel better. =]

Advertisements
Posted in code, java
2 comments on “What if what you’re modeling really is anemic?
  1. Max says:

    Hi,

    the firm I work for has been part of the VSIP last year which is a program to create extension for visual studio. We also had a look at the EULA of express at that time and there can just be no doubt about it, specially when you start to look at the express version and see that extensions were disabled by MS. If a piece of software has its features disabled and the EULA state you can’t enable them its not rocket science to know who’s in breach here and why would MS let it be when firms like us are paying high bucks to be in the VSIP program.

  2. Mike Witters says:

    Thanks for your comment.

    I agree with you that if its stated then it should be limited, especially if there is a program like the VSIP that allows you to extend it by paying a fee. The stuff I read didn’t seem so explicit about it.

    I guess the real question to me, just an observer of all of this, is why does it work? It’s not ‘disabled’ or it wouldn’t work, right? Shouldn’t the API (or ability to use plugins) only be available to VSIPs if this is the way they want it to work? In a case like this, as I said in the post, MS almost certainly has all of the rights and there are probably a hundred details I don’t know about.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Archives
Categories
Blog Stats
  • 6,600 hits
%d bloggers like this: