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

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

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

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

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

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

位置関係

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

集約関係

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

汎化関係

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

関係の線は少なくする

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

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

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

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

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

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

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

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

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

実践 Domain-Driven Design : ユビキタス言語パターンの実践

ICONIXプロセスは、最初にドメインモデル(用語集)を作って、関係者でレビューして、理解が共通であることを確認します。

もちろん「ドメイン駆動」。つまり問題領域の知識を表現する用語を集めるということです。

Domain-Driven Design ( DDD : ユースケース駆動設計 ) では、「ユビキタス言語」パターンとして、関係者の間で、共通の言語を持つ価値、効果を強調しています。

その DDD の「ユビキタス言語」パターンを実践する手段が、ICONIXプロセスの「初期ドメインモデリング」と関係者でのブレスト(おしゃべり)や、要求レビューの活動です。

用語の洗い出しは、業務側が主導する。構造的な整理は技術側が主導する。まず、両者がギャップがどこにあるか、ドメインモデル図で具体的に理解するところから始めるから、ギャップが埋まるのも速い。

開発初期に、ドメインモデリングで、要求側と開発側が同じ用語で問題領域を話すための「ユビキタス言語」を整備する。
ある程度の共通言語ができてから、ユースケースモデリングに進む。だから ICONIXプロセス だと、要求側と開発側がコミュニケーションのギャップが小さくなる。

実践 ドメインモデリング : 業務側の強み+技術側の強み

業務系メンバーのドメインモデルは、業務用語が豊か。
技術系メンバーのドメインモデルは、構造の整理が得意(好き?)。

だから、両者の良いところを融合するれば良いドメインモデルができる。

出発点は、業務用語です。(ドメイン駆動)

技術系メンバーが見落としていたり、理解があやふやな業務用語を明確にする。蛍光ペンでマークする。

理解があやふやでも、そういう「用語(概念)」が必要なんだということを、まず全員の共通理解にする。 蛍光ペンのマークは、まだ理解が怪しい、という文字通りの「マーク」です。

だいたいの配置は、業務系メンバーが主体でやる。 業務の流れと、アクター(部門や役割)別などを意識して。

用語のリストアップとだいたいの配置が共有できたら、技術系のメンバーが主体で集約や汎化関係を描き始める。

業務系メンバーが、その汎化や集約がしっくりくるか、確認する。

こんなセッションをちょっと続ければ、お互いの理解の溝は急速に縮まります。
セッションの最中に「ああそうか」という小さなブレークスルーはなんかも起きるし、うまくいけば、「そうか、これだ」と大声をあげたくなる、大きなブレークスルーが起きる。

実践 ICONIXプロセス : 業務系メンバーのドメインモデル

業務系のメンバーのドメインモデルは、業務用語はたくさんでてくるけど、粒度や性格がばらばら。構造もはっきりしないことが多い。

業務フロー図や画面フロー図を描いてもらうと、わかりやすい図を書いてくれる人が多い。 

業務系の人のドメインモデルへのフィードバックは、業務の手順や画面にマッピングしながら話すと通じやすい。

ドメインモデルという業務プロセス図?

業務の順番で、情報の発生順を少し意識してもらうだけで、ぐっとモデルが整理できる。
業務プロセスのはじめから存在する情報と、プロセスの後のほうでしか発生しない情報とを考えて、左から右に並べてもらう。

上下は、アクター別に整理してもらう。業務プロセス図のスイミングレーンですね。

クラス図といいながら、業務プロセス図的に描くわけです。 もちろん、ドメインモデルは静的な構造なので、時系列や登場人物のスイミングレーンを意識しすぎると、問題もあるんだけど、大きな整理のヒントという意味では、とても有効。

ドメインモデルという画面構成図

なんども書いていますが、ドメインモデルの集約関係は、画面に実装すると、
・同じ画面で表示する情報のグループ

・ある画面からリンクで遷移する画面遷移
になります。

集約関係の中心( Aggregates のルート ) は、この問題領域の中核の情報、画面であるはず。

もし、集約ルートのオブジェクトが、この問題領域の中核としてしっくりこない場合は、モデルを見直し、修正しましょう。

ある視点から見れば正しい構造であっても、現在の問題を正しく表現できていないということです。重要でない関係に注目しちゃっている。

集約ルートのオブジェクトの表示画面、入力画面ができてしまえば、ソフトウェアの主要部分が完成。それだけでも、そこそこ役立つ。
これが正しいドメインモデルの集約関係。

実践 ICONIXプロセス : 業務と技術の視点の違い?

2時間程度で描く初期のドメインモデルを見ると、業務系メンバーと技術系メンバーの特徴がでて面白い。

業務系メンバーのドメインモデル(概念クラス図)は当たり前だけど業務用語が豊か。
ただ、どういう観点で配置・整理しているのかわかりにくい。関連のモデリングも怪しい。あまり構造的ではない感じ。

技術系のメンバーは、まず、業務用語自体、だいぶ見落としがある。似ているけど違う言葉や誤変換をした言葉がクラス名になっていることも多い。
まず、ここらへんの言葉のお勉強から始めることになる。

全体の配置、見た感じの構造は、それなりのものがでてくる。

集約や汎化関係を積極的に使う。
汎化や集約を描ける所は、一見、それらしい構造になっている。
それ以外の部分も、丁寧に並べたりする。(並べ方の意味が不明の時もあるけど)

問題は、見た目に整理できていても、汎化関係や集約関係が「業務の視点」「問題領域の構造」ではないこと。

例えば、組織を汎化関係でツリー構造に描いたりする。
(部門名や役割の認識がおかしかったりするけど、構造はそれっぽい)

でもその構造は、開発するソフトウェアの利用目的、問題領域の知識として、いちばん重要な関係なんだっけ?

私の経験では、組織のツリー構造が重要な問題領域はそれほど多くありません。
今の課題では、どんな部門間の関係が重要なんだ、という視点が、技術者の最初のドメインモデルには、まずでてこない。

ああ、問題が理解できていないんだ、視点がずれているんだ、ということを、2時間程度のお絵かきで発見できるのが、ICONIXプロセスの初期ドメインモデリングの価値ですね。

実践 ICONIXプロセス : みんな考えていることが違うんだ

ICONIXプロセスを本格的に実践しはじめてから3ヶ月。

やってみて驚いたし、この開発手法に手ごたえを感じたのは、最初のドメインモデルを見せてもらったとき。

「ユースケース駆動開発実践ガイド」に従い、各自、2時間程度で描いてみて、見せ合う。

びっくりするのは、
・何をドメインオブジェクトの候補にするか
・どこにオブジェクトを配置するか
・集約や汎化関係
が、人によってめちゃくちゃ違うこと。

これだけ問題領域の捉え方がばらばらだと、そりゃいいソフトウェアは作れんませんね。
それがプロジェクトの初日に発見できるんだから、これはすごい。

もうひとつ驚いたことは、業務側と開発側の会話が楽になったこと。

コード書いてりゃ楽しい的な開発者も、ドメインモデルは「UMLクラス図」なので、それなりに興味を持ってドメインモデリングをやる。

業務に詳しいが技術者でないメンバーは、UML は知らないが、概念クラス図くらいは、それなりにかける。抵抗感もない。(UMLという説明はしていない)

元ネタは同じ画面の紙芝居と要求のメモ書きから、ドメインクラスの候補を抜き出す作業なので、お互いの会話がかみ合いやすくなった。どこから持ってきた用語かの説明がお互いにできるから。
(勝手に別のところからもってきちゃうのが得意な人もいるけど)

最初は、お互いのクラス図(概念)は、一致点をさがすのが大変なくらい。
でも、元ネタが同じで、ドメインモデルの描き方の約束が同じだと、どこが違うかとか、なぜ、そう考えるかの会話ができるようになったこと。

それ以前は、画面が動くようになってから「何、これ?」と声が業務側からあがっただろう、理解の不一致が、プロジェクトの初日に発覚する。

ほんと、これすごいことです。

複雑さと戦う : データと手続きをひとかたまりにする

Domain Model パターンは、データと操作(メソッド)をひとかたまりで考える。基本は、クラスにカプセル化。もう少し広い範囲だと、パッケージにカプセル化する。

データと操作をひとかたまりにするのは、オブジェクト指向の専売特許ではなく、C言語でも、構造体とその操作関数をモジュール( .c ソースファイル ) にカプセル化する。

Java では、コレクションフレームワークとか便利なものがでてきましたが、昔は、.c ファイルに構造体と操作関数のモジュールを自作したっけなあ。

データの入れ物と結びつきが強いメソッドは、まとめて管理するほうが、分かりやすいし、変更も比較的安全にできる。

なんでもデータ+メソッドという気はありませんが、 結びつきがはっきりしていれば、まとめておいたほうが便利だと思います。

「リファクタリング」 もう一つの読み方

マーチンファウラーの「リファクタリング」はリファクタリングのパターン集ですが、例として使われているクラス図やソースコードの中身も興味深い。

・顧客と顧客タイプ
・従業員と従業員タイプ
・製品
・出荷
・価格と割引
・請求と請求タイプ

商品販売や出荷のドメイン(問題領域)でよくでてくるビジネスの知識やルールをドメインクラスとして実装する具体例として参考になる。

たとえば、顧客タイプやキャンペーン期間を元に割引率を変える、というルールを、どう実装するか?

どんな単位でデータやロジックをカプセル化するか。その場合、クラス名、メソッド名、フィールド名は、どんな名前のつけ方をしているか。

シンプルな例ばかりですが、ドメインの知識を「データとロジックをカプセル化」して実装する「ドメイン駆動設計」の良い具体例です。

「リファクタリング」にでてくるのは、ドメイン層のクラスばかりです。
Domain Model パターンの実装コードの例として参考になります。

ドメインモデル貧血症の症状

ドメインモデル貧血症

ひどい症例

使う人が、入力内容を工夫して、本来の機能とは違う使い方で、なんとか役に立てている。
使う人が、出力結果をエクセルに移して、そこで手作業で加工して、なんとか役に立つ情報を得ている。

考えられる原因

・ソフトウェアに問題領域の知識がない。
・ソフトウェアが知っているのは別の問題領域。
・ソフトウェアが問題領域の間違った知識を持っている。
・ソフトウェアは正しい知識を持っているが、利用者に伝わらない。

実装の特徴

・入力データの妥当性検証がほとんどない(何でもOK)
・テーブルに参照性制約がない。
・テーブルに Not Null 制約がほとんどない
・XML スキーマで制限(Rescriction)がない

末期症状というか、それ以前の問題というか。

ビジネスのルール・ロジック・処理判断を、使う人の知識と能力にまかせている。使う人が画面の前で一生懸命に、過去の知識を動員して、注意深く操作することで、なんとかソフトウエアを動かしている。

どう見ても、役に立つソフトェアの姿ではないですよね。

ドメイン駆動の設計・開発、Domain-Driven Design ( DDD ) の実践の第一歩は、「問題領域の知識を正しく持ったソフトウェアは、もっと役に立つ」という価値観です。

同じ結果を得るのが、今までよりずっと簡単になる。今までは欲しくても手に入らなかった情報を見つけることができる。そんなソフトウェアを(楽をして)作りたい。

これが私が Domain-Drive Design をすばらしいと思い、Spring と ICONIX を気に入っている理由です。 三つとも、この価値観を共有している。

実践 ドメインモデリング 日本語と英語のマッピング

ICONIX プロセスでは「プロジェクトの用語集」から出発したドメインモデル(概念クラス図)をしだいに洗練し、詳細化し、最後は、実装クラスの自動生成という考え方。

「ユースケース駆動開発実践ガイド」の原著 "Use Case Driven Object Modeling with UML - Theory and Practice" では、最初に登場した "Book" が、Java で class Book { }まで落とし込まれていく。

日本ではどうなる?

「ユースケース駆動開発実践ガイド」では、ドメインモデリングは「書籍」で出発し、予備設計のロバストネス分析までは「書籍」。
実装設計のシーケンス図でこのオブジェクトが突然 "Book" にしている。

プロジェクトの関係者で問題領域の理解を共通にし、深めるためには、やはりモデリングは日本語でやるべきでしょう。 実装は、英語の名詞・動詞を使うことが多いと思う。Java やフレームワーク側が、クラス名もメソッド名を英語だし。

じゃあ開発プロセスのどこで日本語と英語のマッピングをするのが適切だろう。「ユースケース駆動開発実践ガイド」を翻訳した人たちも、議論があって、実装の前と後のところに線を引いたんだと思う。

でも、ラフなモデルから段階的にドメインモデル(クラス図)を成長させていく、ICONIX プロセスの考え方からすると、実装の直前で、大量の日英マッピング作業を発生させるのは実践的ではない。

最初は属性が無い状態からクラス図を書き始め、振る舞い分析(ユースケースモデリング)をしながら発見した属性を追加していく、ロバストネス分析の完了時には、75%程度の属性が定義済み、という ICONIX プロセスのガイドライン。

日英マッピングもこれと同じようなペースが良いと思う。
まず、最初の用語集(2時間で作るバージョン)は日本語だけでよい。
ここからスタートするときに、少しづつ、英語での表記を追加していく。例えば 書籍:Book のように。

英語へのマッピングは、負担が増えるけど、このマッピングをみんなでブレスト(おしゃべり)することで、モデルとみんなの理解を別の角度から検証という効果がありそう。

このやり方だと、ドメイン層のオブジェクトは、ソースコードレビューをユーザ自身ができてしまうような気がする。まあ、やる価値があるかどうかは別として。

calendar
     12
3456789
10111213141516
17181920212223
24252627282930
31      
<< March 2024 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM