Mats Helander makes a statement that links domain model and O/R mapping.
In my opinion, that statement only sounds revolutionary if it would mean: If you’re not using <my favorite ORM> you’re not using a domain model.
But I don’t think it does. It means, if my objects are to have state persisted in a relational database, I’m about to do O/R mapping.
But whether I need an ORM or not, does not depend on whether I have a domain model or not. It depends on my object paradigm.
If I think objects are cohesive data structures with some functions, well then any ORM might free me from the chores of writing database access. The less visible, the better. Maybe a JDO derivative like OpenAccess will do.
If I think objects are responsibilities, then it’s actually harder to find any generic approach for persisting my object’s state.
But it could be worthwhile thinking through why Microsoft is postponing ObjectSpaces and WinFS.
Myself, I had to dismiss lots of ORMs because they all couldn’t cut it for my colleagues requirements.
Even with OPath or other sophisticated query languages, ORMs just aren’t sustainable bridges across the impedance mismatch. We’re not doing rocket science, but an ORM should not put the RDBMS on a leash. If I’d want that, I’d go with Caché.
I wait for the light at the end of the O/R tunnel. Whenever there is an ORM that goes beyond persistence and also maps significant classes of stored procedures, please let me know.