O/Rマッピングレイヤのありがたさ

データベース設計を担当して実感したことだが。
RDBとオブジェクト指向言語のインピーダンスミスマッチは、データベース設計やオブジェクトモデリングの拙さを隠してくれるありがたいものだ。
理論的な支柱のない素人くさいデータ設計であっても、O/Rマッピングレイヤでゴニョゴニョすることで、アプリケーションに提供するオブジェクトグラフを適切なものにすることができる。
この「ゴニョゴニョ」しなくてはならない理由を突き詰めると、Hibernateのような厚いO/Rマッパーやオブジェクト指向データベースではインピーダンスミスマッチは解消しないことに気づく。
つまり、アプリケーションが要求するオブジェクトグラフと、stableなデータ構造とは一致しないという困った事実に突き当たる。
例えば。
ファウラーの「責任関係パターン」を使って、部-課-係という組織構造をモデリングしたとする。
このオブジェクトグラフを直接アプリケーションに見せてよいかというと、よくないですよ。
アプリケーションでいちいち組織構造を抽象化したオブジェクトグラフを手繰るのはめんどくさすぎますよ。
やっぱり

部#get課()
課#get係()

みたいなメソッドがないと、やってられないですよ。特にViewでは。
「責任関係パターン」を実装しつつ、上記のような便利メソッドを持ったオブジェクトグラフをアプリケーションに提供するには、O/Rマッピングならぬオブジェクト−オブジェクトマッピングをプログラマがやらなくてはならない。それではO/Rマッピングを人力でやるのと変わらないのではないか。
O/Rマッピングレイヤーの存在意義を積極的に認めて、アプリケーションが要求するのとはぜんぜん違う、stableなデータ構造をT字形で構築するのが吉じゃないのか、と。