A while ago I visited this already. Now I think that it is not that bad, at least as I know now how to fix it. A valid remark is of course, why not doing it right in first place, but actually this is why I changed my mind.

In fact, even if you start out with a proper domain model, you might end up later with an anemic one. Or an over-complicated that creates other issues. Another reason is of course that you have a legacy application that is just reimplemented using pseudo OO (”I have get and set instead of public attributes, thus I did OO”)

So the fix. I have to admit that I forgot it. I started writing this post some months ago and abandoned it, then openend it up again as my mind changed, etc.

Now I see two ways to deal with it: Let’s start with the one most people will despise:

The DB-domain model

As virtually every application is based on a RDBMS, you have there all the tables, foreign keys, other constraints and perhaps even some trigger that perform basic checks and completion of your data. Such an implementation where no real business logic is in the DB is a perfect anemic domain model. Question is now: Why should you create another domain model on top of that. In the end the success of Rails is explained for a good part that the database tables form the domain model. No redundancy, no phony layers.

Of course when you change the database schema it ripples back through the whole application. But how likely is that? When I look back at the system I had been involved professionally, this had been a rare event and most of the time there had been things being added and only rarely any modification. This is perhaps due to the quite mature domain I work in (insurance) and to the large amount of data that would have been migrated; this creates some inertia that makes rippling changes prohibitively expensive.

Bottomline: If your DB-model is quite stable, it might be pragmatic to hit it simply with all the SQL you got.

The View-Model

The view-model is addressing the situations which are diametral to both sides of the situation in favour of the DB-domain model. There are two subdivisions, the Generic Data Model and the Overcomplete Table Model. The GDM is easily recognized. Usually there is a huge application and there are only a dozen or so tables. The tables are also not normalized, so find a lot of VALUE_1, VALUE_2,… or many recursive foreign keys and discriminator columns. The Overcomplete model is characterized by tables with hundreds of columns where the majority of the rows contains nulls. Note that in a large legacy application you even find mixtures of it.

There is one way to transform such schema to be suitable for using the DB-model approach: Creating views. But this has two drawbacks/limitations:

1. The views can get pretty complicated and in turn hard to tune (and this works only for reads)
2. You loose row-identity so that parts can modify the same data without knowing

And of course writing data on views is not so easy, it requires either a lot of DB-logic or some serious coding that will be redundant in structure.

If this is not viable, the Anemic Domain Model becomes your friend. In fact the ADM will implement what you’d need to do for transforming it into a DB-model, but without the distribution of the logic between application and RDBMS thereby elimination the redundancies.

On top of the ADM, which just does the DB-handling and ensures row-identity you can than build many domain models which correspond to the views you would have created. By this you might have different classes accessing the same table (sometimes even the same row) which do different thinds. As long as their operations do not intersect no additional logic is required, in case an attribute get co-modified, you’ll need locks or something to coordinate and arbiter.

Where to go if you have the choice

Now you are in a fresh start-up with a funky idea. Which one do you pick? There can’t be a simple answer, but I have decided for myself to prove first that the DB-domain is not working before trying anything else. The reasons are compelling:

• The DB-model is sufficiently simple and expressive at the same time to discuss it with the stake holders
• Rapid prototyping is available in different variations (Rails & Co or even Forms and Powerbuilder)
• By delegating virtually all data handling into the DB you profit the most from the elaborated caching and optimization techniques and their scalabilty - assumed you use a modern RDBMS

If the application relies less on structured data or the approach simply doesn’t fit your culture - DON’T use it. The DB-domain model is very committing and if you cannot be sure to have a good idea about the structure of your data, you’ll spend your time rewriting your queries.