プロジェクトの初期段階において最も重要なのは、
システムが取り扱う「もの」の概念について、チーム内で共通認識を築くことです。
これを怠りなんとなく実装を進めてしまうと、後半になって、

Aさん「あれ？この言葉ってこういう意味じゃないの？」
Bさん「え？そうじゃないよ。もしかして認識ずれてた？・・・」
↓
認識ズレ発覚！といった状況が発生することでしょう。

そこで、プロジェクト開始時にドメインモデル図を描くことで、
主要な「もの」の概念についてチーム内で共通認識を固めることができます。

ドメインモデル図とは、ユーザの視点で見た、システムに登場する「もの」の概念（ドメインクラス）を集めた図です。プロジェクトの用語集をクラス図風に表現した図ということにもなります。ドメインモデル図は自然言語で構成するため、要件定義や仕様の把握に有効です。

ここでは、ICONIX Process（ユースケース駆動型のオブジェクト指向開発プロセス [1]）を基とした、ドメインモデル図の描き方を説明します。

図の初期設定
ドメインモデル図を描くソフトは、クラス図を描けるソフトであれば何でも構いません。
ここではUML描画ソフトとして、astah* communityの画面を例にしています。

まず、クラス図を新規作成し、図の名前を「ドメインモデル図」とします。

モデル名と属性だけ見えれば良いので、その他の情報を非表示にします。

以上で、ドメインモデル図の準備が出来ました。

ドメインモデル図を描く
まず、要件ドキュメントやヒアリング結果から「名詞」を抽出し ます。
例えば、通販サイトの要件から以下のような名詞が抽出されたとします。

「商品、型番、価格、カテゴリ、カート、注文、レビュー、ウィッシュリスト、ユーザ、登録情報、メールアドレス、など」
これらのユーザの脳内の認識（概念）へとつながる名詞が、ドメインモデルを構成するわけです。

次にこれらの名詞を、図に並べていきます。
名詞は「ドメインクラス、ドメインクラスの属性、アクタ」の3種類に分けられます。

判別方法を簡単に説明しますと、
1. ユーザや、外部システムは「アクタ」です。
2. 商品の型番や、商品の値段など、○○の△△として書けるものは「ドメインクラスの属性」です。
3. その他の名詞は、「ドメインクラス」です。

ちなみに、アクタを図に追加するためには、ツリーからフォルダを右クリックし、「モデルの追加→アクタの追加」をクリックします。
そしてツリー上のアクタを、図上へドラッグ＆ドロップします。

意味が重複してしまっている名詞があれば、図上で統一しましょう。
例えば、「値段」と「価格」などです。

次に、モデル同士の関係を、線と矢印で表します。
線の種類は、「has-one, has-many, is-a-kind-of」の3種類だけでOKです。

例えば商品に「在庫商品、予約商品」の2種類があるとすれば、下図のように表します。

中心となるモデルに色をつけて強調し、完成です！

実際にはもっと広い図になると思いますが、描き方の流れは以上のようなトコロです。
描いたドメインモデル図は、プロジェクトの用語集として活用しましょう。

最初に図を描いた時点では必ず、図のどこかに「認識があいまいな部分」が出てきます。
あいまいな部分を発見したのは勝利と見なして、仕様の再確認を行いましょう。
また、プロジェクトが進行して仕様変更が出てきたとき、ドメインモデル図は概念の再確認の場として役に立ちます。

ドメインモデル図の利点まとめ
ドメインモデル図には以下のような利点があり、要件を理解するために「最初に描く図」として適しています。

● プロジェクトの用語集を形成でき、チームで共通認識を固められる。
● 自然言語で表現することが前提なので、誰でも理解しやすい。
● 抽象度の高いクラスモデルであるため、ER図のようなデータ中心の図と違い、DBに存在しないモデルまで表現できる。例えばショッピングカートのようなセッション内のオブジェクトなど。

ドメインモデル図の別の呼び方
ところで、「ドメイン」と言えば真っ先に思いつくのはドメインネームなので、ドメインモデル図と言っても分かりづらいですよね。かといって直訳して領域モデルと呼ぶのも分かりづらいです。そこで私は、ドメインモデル図のこ とを「概念モデル図」と呼んでいます。

注意点
後にシステムの詳細設計を行う工程でも、意味的なモデルであるところのドメインモデル図の更新を怠らないようにしましょう。そうしないと、要件とコードの間で仕様齟齬が発生しかねませんし、新しいプロジェクトメンバーが加わった時に「意味的な」仕様を説明するのが困難になります。

      
参考文献
[1] Doug Rosenberg and Matt Stephens, Use Case Driven Object Modeling with UML: Theory and Practice. Apress, 2007.