<< ドメインモデル貧血症 | main | オブジェクトの粒度:小さなオブジェクトに分ける >>

オブジェクトの粒度 最小単位

ドメインオブジェクトは、どの程度の大きさに設計するか?

小さくする

Java の場合は、できるだけ小さくしている。 単一で明快な責務を持たせるのが原則。

では、

テーブルは?
XML は?
UML のクラス図は?

Java と同じ粒度まで、テーブルやXMLを小さくしてしまうと、扱いにくくてしょうがない。

クラス図も、ひとつひとつのクラスを箱に書き出すと、モデルとして役に立たないくらい、図が複雑になっちゃう。

大きくする(まとめる)

一つのテーブル、ひとつのXMLにたくさんのオブジェクトをぐちゃっと詰め込むのは、明らかにアンチパターン。
設計原則「関心事の分離」に違反している。

かといって、分割しすぎるのも問題。
マーチンファウラの PoEAA の「組込みオブジェクト」パターンの議論で、ここらへんが書いてあったような気がする。
後で調べてみよう。

不一致

どうやら、Java 、テーブル、XMLは、同じ粒度で扱うのは現実的ではなさそう。
不一致が発生するわけだ。
この不一致をどうやって吸収するかも重要な設計問題になる。

ここらへんの実践的なやり方を、少し検討していきたい。

コメント
コメントする









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