<< 実践 Domain-Driven Design : ユビキタス言語パターンの実践 | main | 実践 Domain-Driven Design : 7章を読み直し >>

実践 ICONIXプロセス : ドメインモデル図 > 用語集

ICONIXプロセスでは、ドメインモデルを「用語集」だと説明している。

表現方法は概念クラス図。

・クラス名だけ (属性、操作は書かない)
・集約と汎化は描く

・多重度は記入しない
・アクターを同じ図に描く
・外部システムを同じ図に描く

50音順の(ほんとうの?)用語集に比べ、ドメインモデル図がすぐれている点は次の通りです。

位置関係

ドメインオブジェクトをどこに配置するかは、人によって異なる。
配置の違いは、概念をどう理解しているか、何を重要と考えているかを反映します。ですから、同じ用語の集合でも、位置関係の違いで、お互いの理解のギャップを発見したり、確認できます。

集約関係

集約関係は、そもそも意味が共通理解にするのがたいへんですが...
人によって、何と何を集約と考えるかは、ほんとうにばらばら
これも、お互いの理解のギャップを発見するのに役にたつ。

汎化関係

汎化は、集約よりは、意味は共通理解にしやすい。
でも、何を同じグループと認識して、そのグループの名前(スーパークラスの名前)に何を使うかは、人によって変わる。
知識や理解のギャップを、この汎化関係で見つけて修正できることも多い。

関係の線は少なくする

集約と汎化でお互いの理解を違いを発見するためには、関係の線は少なくする。自分が重要だと思うものに限定して描いてもらう。
そうすると、何を重要と考えているかの違いが明瞭になる。

5本に限定してごらん、というような実験をしてみると、違いが明瞭になって、わかりやすい。

重要オブジェクトのみの抜粋版を描く

Enterprise Architect などのモデリングツールを使うと「モデル」と「図」は分離できます。
ひとつのモデルについて、いろいろな視点の図を描くことが、ドラッグ&ドロップで簡単にかける。

この機能を使って、重要(だと思う)オブジェクトだけ抜き出した抜粋版のドメインモデル図を描いてもらう。 
これはとっても面白い結果がでます。なるほど、こいつは、こう来るか、という感じで、理解の違い、価値観の違いがはっきりする。

あと、抜粋版の図の「名前」の付け方も興味深い。「重要だと思っていること」に名前をつけるわけです。 どういう視点で、オブジェクトを抽出したのかが具体的にわかる。

若手の技術者なんかは「抜粋版1」とか命名してくる。

そうじゃないよね、何かに注目したから抜粋したんだよね。何に注目したんだっけ?
というブレスト(おしゃべり)しながら、理解のギャップを埋めていく。

ドメインモデル図は、お互いの頭の中を見せ合う、ほんと、良いコミュニケーション手段です。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
    123
45678910
11121314151617
18192021222324
252627282930 
<< June 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM