ども、皆川％なんだかいろいろバタバタしてます＠豆蔵です。
# いつもの事ながらレスポンスがたいへん遅くてすいません m(_ _)m
# 現実逃避にかまけて、ちょっと長めにずらずら書いてしまいました。ご興味と
# お時間のある方だけお読みいただけると幸いです m(_ _)m
# 以下、例によってメールの引用部分を一部削らせていただいています。
On Wed, 09 Feb 2005 10:04:05 +0900
kiminobu-kodama@....jp (児玉公信) wrote:
> > この「モデルの所有者はモデルに登場させないこと」というルール(のような
> >モノ)はいったいどこから広がったのでしょうね？
>
> 私が言っています。
あ、なるほど (^_^;
ところで、なぜ児玉さんは「モデルの所有者はモデルに登場させない方が良い」
とお考えになっているのでしょうか？
# 「いろいろと弊害が起こる場合がある」というのはなんとなく想像できるので
# すが、私の心の中では思い付くどの理由も決定打になっていないのです…。
> > いろいろな方々のモデルを拝見させていただくと、どうも今回の課題の場合の
> >「モデルの所有者(?)」である「きつね」に相当する概念(私は「コンテキスト・
> >クラス」などと呼んでいます)をクラスとして「出す派」と「出さない派」とに
> >流派が分かれているように思えます。たとえば、よくある「図書館問題」のクラ
> >ス図を記述したりなんかすると、「本」や「図書目録」などと並んで「図書館」
> >そのものをクラスとして登場させる人と登場させない人とに分かれます。
>
> 実装上の都合で「図書館」が出てくることはあるでしょう。それは
> ドメインのモデルではなくて，アプリケーションファサードとして出
> てきていると思います。
>
> ドメインレベルで「図書館」が出てくるということは，そのモデル
> は図書館のオーナーのモデルではなく，「図書館連合」とか，何とい
> ったらいいか分かりませんが，１つの図書館を越えたモデルになって
> いるのではないでしょうか。
# なんとなく、「ドメイン・モデルってどんなものだろう？」という話題に繋がっ
# ていきそうな予感が(ほんの少しだけ)しますが… (^_^;;
児玉さんの仰りたい事は良く解かりますし、私も「おおむねAGREE」なのです
が、それでも尚、コンテキスト・クラス(対象としている世界を代表するような
オブジェクト)を置いた方がモデルの使い勝手が良くなるケースが多いように思
うのです…。
ここで言っているコンテキスト・クラスとは、実装上の都合で出てくる「アプ
リケーション・ファサード」とは少し役割が異なっているモノと(私は)考えてい
て、ドメイン中に存在する主要要素の基点でありメディエータとなるモノとして
登場させることが多いです。
たとえば、ものすごく単純化した図書館問題を想定したとして、そのドメイン
・モデルのもっともプリミティブな形は次のような感じになると思います。ここ
では仮にこのモデルを「第一段階モデル」と呼ぶことにしましょう。
+----------+
| 図書情報 |
+----------+
| 1..*
0..* |
+----------+
| 貸出記録 |
+----------+
| 0..*
1 |
+----------+
| 会員情報 |
+----------+
# 「貸出記録」は複数の「貸出明細」で構成されているかもしれません。
これだけでも「図書館問題」の立派な(純粋なエンティティだけの)ドメイン・
モデルとして成り立っています。このレベルはデータ中心アプローチ(DOA)だろ
うがオブジェクト指向(OO)だろうが(ほぼ)共通に出てくるモデルの核となる部分
ですね。
ところが、これだけだとモデルの使い勝手がイマイチ良くないのです…。たと
えば、ユースケース毎にロバストネス分析とかしてみると、「図書の検索は誰に
お願いすれば良いの？」とか、「新規会員は誰に登録(追加)すれば良いの？」と
か、主要エンティティの保持/検索などの基本的なところで疑問が出てきてしま
います。これは、各エンティティの集合を保持/管理する概念が登場していない
ためで、ここでは仮にその役割を持つモノを「図書台帳」とか「会員台帳」とか
いった感じで出してみましょう。これを「第二段階モデル」と呼ぶことにします。
+----------+ 0..1 +----------+
| 図書台帳 |◇--------| 図書情報 |
+----------+ 0..* +----------+
| 1..*
0..* |
+----------+
| 貸出記録 |
+----------+
| 0..*
1 |
+----------+ 0..1 +----------+
| 会員台帳 |◇--------| 会員情報 |
+----------+ 0..* +----------+
# さらに複数の「貸出記録」の集合を管理する「貸出台帳」のようなモノが登場
# してくるかもしれません。ただし、すべての「貸出記録」の集合は「図書情報」
# の集合や「会員情報」の集合から間接的に導出することができるので(少なく
# とも単純な世界では)必須とはならないでしょう。
このレベルのモデルで、複数の「図書情報」や「会員情報」の集合を{扱う|表
現する}基点が得られたので、「図書(蔵書)を検索する」とか「新規会員を登録
する」とかいったユースケースのコントロール・クラスはこれらの「〜台帳」に
基本的なエンティティのアクセスをお願いできるようになります。
# これは反論があるかもしれませんが、私はこれらの「〜台帳」に相当するクラ
# スをコントロール・クラスではなくてエンティティ・クラスの一種だと見なし
# ています。これらは、同種のエンティティ群のある集合を表現し、追加/削除/
# 検索などの基本的な集合操作のみを提供しているモノだからです。
さて、少しモデルの使い勝手が良くなってきましたが、ここでちょっといくつ
かの疑問が発生します。
その疑問のひとつは、『この世界(問題領域)には、いったいいくつの「図書台
帳」や「会員台帳」が存在しているのだろう？』というものです。実際の図書館
の概念をなんとなく知っている私達は、上の第二段階モデルを見て暗黙的に「そ
れぞれの台帳は(この世界に)ひとつずつ」といった思い込みをしてしまいがちで
すが、このモデル図ではそれは明記されていません。もしかするとこのモデルを
作った人の認識はそれ(暗黙的な思い込み)とは違っている(たとえば「一般の会
員用と特別会員用とで別々の会員台帳を作る」などと考えている)かもしれませ
ん。何らかのコメントや制約を忘れずに明示するなどの対処をしないと、この認
識のズレは回避できません。
疑問のもうひとつは、『どうやって特定の「〜台帳」を得れば良いのだろう？』
というものです。たとえば、各ユースケースのコントロール・クラスは、そのユー
スケースの(アプリケーションとしての)機能を実行(手順を制御)するために、ド
メイン・モデル中のエンティティ群(特に「〜台帳」)を参照/利用します。これ
らのコントロール・クラスは自分が利用する「〜台帳」を「知っている」必要が
あるのですが、上記の第二段階モデルではそれ(特定の「〜台帳」を得ること)を
頼めるような要素が登場していません。『各コントロール・オブジェクトの生成
時に*実装上の何らかの手段*を用いて必要な「〜台帳」の参照を得る』といった
「逃げ」を採ってしまうという手もアリかもしれませんが…。何にしろ、各コン
トロール・クラスが「〜台帳」を直接個別に参照するような構成は、ドメイン・
クラスのレイヤとコントロール・クラスのレイヤとの結合度を上げてしまうので
あまり嬉しい方法とは言えないような気がします。
以上のような{疑問|課題}を解消しやすくする(モデルの使い勝手を高める)た
めに、あえて「図書館」のようなコンテキスト・クラス(対象世界を代表する基
点となるようなオブジェクト)を置いてモデルを{考える|表記する}ことを(私は)
よくやります。コンテキスト・クラスを導入した「第三段階モデル」は次のよう
な感じになります。
1 +----------+ 0..1 +----------+
+----| 図書台帳 |◇--------| 図書情報 |
| +----------+ 0..* +----------+
| | 1..*
0..1| 0..* |
+--------+◇---+ +----------+
| 図書館 | | 貸出記録 |
+--------+◇---+ +----------+
0..1| | 0..*
| 1 |
| +----------+ 0..1 +----------+
+----| 会員台帳 |◇--------| 会員情報 |
1 +----------+ 0..* +----------+
これで『(現在対象にしている)「ある図書館」では、「図書台帳」と「会員台
帳」を「明確にひとつずつ」取り扱っていること』が明示されますし、『図書台
帳」や「会員台帳」は誰によって管理されているのか』という点も一目瞭然にな
ります。何よりも、このモデル全体の構成は、現実世界での私達人間の認識とマッ
チングが良い(類推が利きやすい)ように(私には)思えます。つまり、「図書台帳」
や「会員台帳」がフラフラ浮いているように見える第二段階モデルに比べ、第三
段階モデルでは『ある「図書館」の中には、図書の一冊一冊に相当する情報を書
いた紙(「図書情報」)が閉じられているバインダー(「図書台帳」)と、登録され
ている会員の情報を書いた紙(「会員情報」)が閉じられているバインダー(「会
員台帳」)とがあって、…」といった感じの世界観が把握しやすくて、いろいろ
とモデルの使い勝手が良くなるように思えるのです…。
以上、単純な図書館問題を例にして*私が*「図書館」クラスを登場させるに至
るまでの思考の推移をざっと書いてみましたが、いかがなもんでしょうねぇ…。
--
／|／| ▲ 皆川 誠 ＠ 株式会社 豆蔵
/ ノ / } 「きつねはコンと鳴く」
|// ノ / | 会社用: kitsune@....com
=o=|＼| / 自宅用: kitsune-san@....com
く | / 携帯用: kitsunex@....jp
■■■■