<< オブジェクトの粒度:小さなオブジェクトに分ける | main | ドメインオブジェクトの粒度 : XML とのマッピング >>

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

ひとつ前の記事で書いた、ドメインモデルをテーブルに実装すると、こんな感じ。

データモデル

クラス図とJava の実装ではクラスの数は、7つだったけど、テーブルは2つにした。

オブジェクト指向設計だと、ドメインのオブジェクトは、とても小さな単位になる。String や Integer などプリミティブなオブジェクトレベルまで、ドメインの用語のオブジェクトを作るのが基本。

それぞれのオブジェクトの役割が明確になり、ロジックの置き場所の見通しが良くなるから。

この小さなオブジェクトたちを、1対1でテーブルにマッピングすると、扱いにくいのは直感的にわかる。
オブジェクトとテーブルのマッピングの考え方は?

Aggregate(集約)

Evans のドメイン駆動設計(DDD:Domain-Driven Design)の基本パターンのひとつに Aggregate(集約)の設計がある。
いくつかのオブジェクトをまとめて、ひとかたまりで考える。

DDD の説明では、Aggregate パターンを、オブジェクトのライフサイクルの文脈で説明している。

・オブジェクトを新規に生成する
・オブジェクトを保存する
・保存したオブジェクトを取り出す
・オブジェクトを消去する

こういう時に、いつも、一つのグループとして扱うべきオブジェクトのかたまりを見つけることが、ドメイン駆動設計の基本テクニック。

DDDの本では、このオブジェクトをひとかたまりに扱う感じを、ブドウの房の写真で象徴している。

どういう単位が Aggregate として、ひとかたまりとして扱うべきかの議論が、ドメインを深く知るための重要な手がかりになる。

オブジェクトのテーブルへのマッピングは、この Aggregate の設計を反映するのが基本。

大きさの制限

ただし、テーブルも、基本は役割別に小さくしておくべき。
なんども繰り返しているけど、関心事の分離は、設計の基本中の基本。

乱暴だけど、テーブルのサイズは、属性を5つくらいまでを目安にしている。

主キー、外部キー、タイムスタンプなどの監査列を除いた、値を持つ列が、5つを超えたら、テーブルの分割の可能性を考える。

もちろん、情報のかたまりの意味を優先するけど、データ列が10を超えたら、完全に、アンチパターン(肥大化したテーブル)と判断している。

テーブル設計の手がかり

実践的には、テーブルの単位は、画面上の「ブロック」を参考にしている。

例えば、画面の氏名の入力フィールドが、

・姓
・名
・セイ
・メイ

4つあると、デザイン的に、4つのフィールドを枠線で囲ったり、背景色を変えたり、「氏名」という見出しをデザインしたりして、ひとかたまりに見せる工夫をする。

このグループが テーブルの単位の第一候補。

業務上、意味があるかたまりだから、そういうデザインにする。そういう論理的なかたまりは、当然、モデリングに反映すべきだし、Aggregate の実装、テーブルの実装でも、意識すべき論理構造。

コメント
コメントする









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