ここからは、これまでの部分的な問題にフォーカスしたパターンから、包括的にO/Rマッピングを扱う「オブジェクトリレーショナルメタデータマッピングパターン」となります。
Metadata Mapping は、手作業プログラミングによるクエリ結果からオブジェクトへの転送ロジックを書くのではなく、ロジックと無関係な宣言的メタデータを使って、包括的にマッピングを実現するメカニズムを導入するパターンです。
小さなプロジェクトであれば、これまでの振る舞いと構造のパターンを意識した Data Mapper を自作することも不可能ではありません。Unit Of Work は少し難しいかもしれませんが、使われる状況が限定的なら、プロジェクト固有の事情に甘えることができるので、不可能とも言えないでしょう。
しかし、大きなプロジェクトになってくると、Domain Model のロジックよりも、自作したマッピングのメカニズムのほうが大きくなり、バグの温床になってしまいます。Domain Model は純粋な単体テストが可能ですが、全てのマッピングが正しく動いているかを確認するには、データベースの実体が必要です。
手作業の辛さを解消するには、メタデータでマッピング戦略を指定できる O/R マッパーライブラリを活用するのが最適です。PoEAA が紹介したパターンを使って、データベースの事情から完全に切り離しながら Domain Model を描いているのなら、パターンに忠実な Data Mappaer に差し替えても、Domain Model のデータ構造とビジネスロジックには何の影響もないはずです。
PoEAA には、言語内 DSL のようなレイヤーや、外部の設定ファイルによるメタデータ割当が紹介されています。現代と PoEAA が書かれた頃とが異なるのは、Java や PHP などのクラスとメソッドを明確に書くタイプの言語に、自由なメタデータを埋め込める文法が追加されたことです。ロジックとは無関係に、ソースコードに任意のマーカーを埋めておける仕組みです (Python のデコレーターは、記法こそ似ていますが、関数それ自体の振る舞いを変更してしまうので、メタデータではありません)。
Java の JPA は、この、「ソースコード内のメタデータを利用して O/R マッピングを行う」にあたって、ライブラリベンダーの差異を減らすことを目的として定められた、業界標準のアイデアです。大多数のマッピング設定を JPA に従って書き、ベンダー固有の機能設定だけベンダー固有アノテーションをつければ、万が一ライブラリの移行が必要になったとしても、Domain Model への変更を最小化 (しかもそれは一部のメタデータなのでロジックは全く変えなくていい) できて安心です。
ソースコードにメタデータを直接書き込むことを嫌う人もいます。しかし、メタデータはプログラムに直接的な影響を全く及ぼしません。データベースと接続しないかぎり、これまでの単体テストはこれまでどおり、すべてパスします。ソースコードに埋められたメタデータは、本質的には外部ファイルに分けて書いたメタデータと何の違いもありません。もしソースコードへの変更が頻繁に起きて、Domain Model のリファクタリングとマッピング時の SQL チューニングの作業がコンフリクトしやすいなら、衝突しやすいこと (継承マッピングの選択など) だけを外部ファイルに分けておき、変わりにくいこと (フィールドの名前と型など) だけをソースコードに残す、といったアイデアも考えられます。
Domain Model への影響がないことから考えれば、Metadata Mapping もまた、選択肢のひとつにすぎません。かならずしも Data Mapper の特徴の全てが必要というわけでない場合には、個別のパターンを参考に小さく手作りする選択をしても、けして間違いではありません。