David HH has put up an interesting comparison between tada list, and the recently launched blabla list. I’m not really interested in carrying on the language war, I like both languages, but he did hit on one point that confuses me about a lot of java aplications:

What surprised me the most was the lack of a real domain model. Apparently, the model in Blabla is just a bunch of data containers while the logic is in a service/controller layer. Ouch I sure don’t hope that procedural excuse for an object-oriented system is par for course with RIFE

In reality, an Anemic Domain Model is quite common in Java applications. Most Java applications I’ve worked on have lots of well thought out classes doing nothing more than getX/setX/isX, i.e the object oriented features of Java are being used for little more than statically typed HashMaps. The business logic of these applications typically lives in large procedures with signatures like:

public void authorisePayment(User authoriser, Payment payment);

Rather than having an authorise method on the Payment class, we build infrastructure to get ‘service beans’ from some kind of container. We have so many of these ‘service beans’ that we need a fancy solution to create and manipulate them. Spring is great, but the fact that most projects seem to use it to store Transaction Scripts

Now it’s widely known that it’s a bad idea to have your business logic in your controllers, but moving it into some other procedural ‘class’ isn’t really that much better. When you have a 1-1 relationship between controllers and ‘service methods’, you’ve really got a problem. I’m not suggesting that object oriented development is the only way to build software, anyone who claims they’ve found the one true way is deluding themselves. Ted leung makes the point succinctly that:

Using the best tool for the job applies to programming paradigms too.

I just can’t see why you’d want the worst of both worlds. All the costs of building classes to represent your business, but without the benefit of using them to implement your business logic. I realise that some of our old APIs (EJBs especially) encourage this ‘empty object’ approach, but with modern java libraries like Hibernate, Spring and insert-your-favourite-web-framework there’s really no excuse any more.

Perhaps this is why so many java developers are really annoyed by the fact that Rails derives the names and types of attributes from the database. In reality the attributes aren’t really that important, it’s behaviour and associations that drive applications. But in an application with an anemic domain model, without attributes you have nothing.