<< Repositories パターン : データベースの実装は忘れようね | main | ドメインロジックのパターンは、ドメインモデルだけなの? >>

ドメインオブジェクトとテーブルのマッピング

Repositories パターンは、ドメインモデルを、純粋にドメインの関心事だけに保つモデリングテクニック。
ドメインオブジェクトのモデリング、設計・実装は、シンプルで、わかりやすくなる。

でも、永続化の実装がシンプルになるわけではない。
特に、ドメインオブジェクトとテーブルのマッピングは、悩みどころですよね。

マッピング自体は、iBatis とか、O-R マッピングのフレームワークを使えば、それなりに実装できる。
でも、ドメインモデル(オブジェクトモデル)とデータモデルの、モデルの不一致は O-R マッピングツールが解決してくれるわけではない。

既存データベースと無理やりマッピング


Repositories パターンを使い始めたころは、既存のデータベースを使うアプリケーションだった。
ドメインモデルとデータモデルが、かなりギャップがあったけど、iBatis SqlMap でがんばった。

「既存データベース」と無理やりあわせる、この状況は、現実には、多いですよね。

Repositories パターン、O-R マッピングフレームワークは、まあ、こういうギャップを埋める技術、と素直に考えていた。

データベースも新規設計


データベースも含めて、新規に設計するプロジェクトがはじまった。

さて、ドメインモデルとデータモデルはどうする?

A案:できるだけ一致させる
B案:ドメインモデルはドメインモデル、データモデルはデータモデル

最初はA案


ドメインオブジェクトといっても、フィールド数が多く、画面をそのままオブジェクトにしたようなモデルだった。

だから、
・画面(のブロック)
・ドメインオブジェクト
・テーブル
は、ほぼ同じサイズで、同じ構造で設計・実装した。

・顧客詳細画面
・Customer オブジェクト(単独の大きなオブジェクト)
・Customer テーブル

ドメインオブジェクトは小さく、テーブルも小さく


Domain-Driven Design を読み始めた影響もあって、オブジェクトを小さくする方向に転換した。

ひとつの大きな Customer オブジェクトを、Entity と Value Object に分解。
もちろん、Aggregate にして、「いつも一緒」に扱うようにした。

このとき、テーブルもそれなりに分解することにした。

厳密に粒度の一致を重視したわけではないけど、ドメインモデルで、オブジェクトを別にするのは、業務の考え方がそうなっているから。 だったら、テーブルもそういうサイズで扱うのが正しいはず。

自然に、テーブルも、小型のオブジェクトに対応させる方向になった。
(よく考えて、そうやったわけではない)

やってみたけど...


テーブルを小さくしてみたけど、あまり良いことはなかった。

逆に、問題がいろいろでてきた。

SQL文で、10以上もテーブルを JOIN するとか、ひとつの Aggregate のために、複数の SQL 問い合わせを実行するとか、コードが込み入ってきた。

ドメインオブジェクトの実装コードは、オブジェクトを小さくわけたほうが、可読性や、変更性がよくなることを実感。
でも、テーブルは、小さくわけても、メリットは何も感じなかった。

テーブルの意図がわかりにくく、コードが複雑で、変更がたいへんになっただけ。

マーチンファウラーの「エンタープライズアプリケーションアーキテクチャパターン(PoEA)」を読み直したら、

「小さなオブジェクトにテーブルを一致させるなんてばかげたことやるやつはいない」というようなことが書いてあった。

なんだ、そうなんだ。

テーブルは Entity 単位に


その後は、だいたい、Entity と 関連する Value Objects をひとつのテーブルにしている。
Aggregate に複数の Entity があれば、Entity ごとのテーブルにする。

とは書いてみたが...


実際は、そんなにちゃんとモデリング、設計・実装ができてるわけじゃないな。

・Entities パターン
・Value Objects パターン
・Aggregates パターン

いちおう、意識はしているけど、なんとなく、

・オブジェクトは小さい単位に
・テーブルはもうちょっとまとまった単位に

という「感覚」でやっているのが実情ですね。

たぶん、「テーブルは、こんな感じのまとまりで」と考えているところを、ちゃんとやるのが、Aggregates パターンなんだと思う。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
    123
45678910
11121314151617
18192021222324
25262728293031
<< August 2019 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM