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. =]