Domain Drivel
Computer science tells us there are three ways to represent data:
- Object graphs (i.e. Java or C#)
- Relational data (RBMS)
- Hierarchal data (XML or HTML)
During the years, we’ve found out about the Impedance Mismatches between these three representations. At first, it seems pretty easy to convert a row in a database to an object. However, things are not so easy as they seem.
And yet, conversion between these representations is all we do in a standard Web application! Data is generally stored in relational databases, and converted to Java or .NET objects using some kind of ORM tool. Next, we use the objects to invoke business logic, and finally, we display them on an HTML page. I find this very amusing, it makes me feel we are doing something wrong here.
Recently, though the influence of books like Domain Driven Design, it has become fashionable to think that a rich Domain Model is one of the most important things there is. Well, that might be the case for you as an OO developer, but for the Enterprise the database is much more important. It is not without reason that a large number of databases outlive the applications built around them. And for the user of your Web application the most important part is the HTML UI he or she is looking at. Finally, in this SOA day and age, the OO business logic is probably not the only business logic that is there. Your application is part of a team of services, the business logic on the mainframe is just as important!
Now, I’m not saying that a rich domain model is not important. I’m just saying that — as with any solution — it is not a silver bullet. Use it when it gives an advantage, but don’t swear by it. In the grand scheme of things, your precious OO model is not as important as you think it is.
EDef said,
October 12, 2006 @ 20:57
Agree 100%
…Although you’ll get no love from TSS and all the MFowler (or anyone else who thinks OO programming is the center of the software universe)…
so many people get wrapped up in trying to provide n-levels of abstraction coughhibernatecough or software patterns that try to solve this inherent “impedence mismatch coughTableDataGatewaycough that they forget that the Data is King not some ephemeral oo process that some website is trying to accomplish…(try working for a financial institution and you’d get that).
The major things I see with Rich Domain is:
1) Ok now I have a domain model with data AND logic… what if the logic is correct in one process/context (i.e. online OLTP order acceptance)… but Similar, yet not OK for another context (i.e. Auditing/ OLAP reporting)…
2) Say I’ve persisted a version of my model many years ago, now I need to reconsititue it, but it fundimentally violates the validation rules in the Rich domain model… now what, do I need to keep multiple versions of the domain model handy, or have ways or relaxing constraints/logic?
3 cheers for anemic domain!
E.
Geir said,
October 12, 2006 @ 23:38
I agree with you conclusion, but I don’t think your argument about domain models being less important because a relational schema has a longer shelf life than program code makes sense.
Databases are used as business interfaces. Any published interface is going to be more stable than a (hopefully private) implementation of business rules. You will find the same issue in any published interface - it is going to be painful to change it, so you often don’t.
I also think Scott Ambler makes a lot of sense when he says that database design is lagging behind program design - database design tools lack any kind of sensible refactoring support. I have yet to meet a DBA with an active perception of how to go about refactoring a database model. This makes changing databases even harder.
Luca Garulli said,
October 13, 2006 @ 13:32
I think that a good OO model with a tool that “reads” your model and simplify your application development is the best!
This is missed from IT industry! Why I should spend my resources to be puritan about my OO model and then convert it in DB and other?
We need a tool that handle own OO model in all aspects: RomaFramework is an effort in this direction
My 0,02
David Levy said,
October 16, 2006 @ 2:03
I think there’s a nice middle ground here: it’s often not hard when designing a new application to ensure that the back end data is in a format which is not too domain dependent. Serializing objects into the database as bytes is probably one of the only things which will absolutely tie you to the language above. Anothing is having complex class hierarchies which should be minimized if possible (although not at a cost of having overly complex objects on top). As long as those two things are kept to a minimum, the backend should be fairly readily available for another application to plug on later or in tandem.
Claudio Perrone's Monologues said,
October 22, 2006 @ 14:16
Crested Butte - The Prologue
Stefan Tilkov's Random Stuff said,
October 25, 2006 @ 16:28
BeJUG Enterprise SOA Conference
I gave a talk at yesterday’s Enterprise SOA Conference, organized by BeJUG (the Belgian Java User Group). It was a very nice event that gave me a chance to meet a bunch of interesting people from the SOA community; here is a short summary. (If yo…