ドメインモデリング
ユースケース駆動開発実践ガイドの第２章のまとめになります。書籍を読む際の参考になれば幸いです。
ICONIXでの最初のプロセスは、ドメインモデリングになります。ドメインモデルはクラス図のプロトタイプとなる静的な設計図です。また、動的な設計であるユースケースを作成する準備作業になります。
このドメインモデリングで最も重要な事は時間をかけすぎないという事です。これはICONIXが設計を段階的に作成していく特長が大きく現れている所でしょう。また、学習する場合もあまり時間をかけすぎない方がいいと思います。この後のプロセスであるユースケース・ロバストネス分析までの一連の流れを把握することで、ドメインモデルは重要であるが最初のステップで時間をかける事が無意味だということが理解できます。
目的
ドメインモデリングの主な目的は２つあります。
１つ目の目的は、ドメインモデルを用語集（ライブディクショナリ）とすることで、設計時の用語のブレを抑えることです。特にユースケースシナリオを記述する時に様々な問題領域のオブジェクトの用語を記述することになりますが、あるユースケースでは利用者で別のユースケースではユーザ、といった単語の差異を予防する効果があります。また、差異があったとしても同じ意味であれば後から統一させるだけで済みますが*1、似たような単語で違う意味の用語がある場合もあります。そのような用語のブレを回避するための用語集としてドメインモデルを利用します。尚、用語集といっても各用語の意味を記述するわけではありません。そのプロジェクトで使用する単語の集まりです。
２つ目の目的は、関係者間のコミュニケーションを円滑に進めるためです。ここで言う関係者とは開発者だけではなく、クライアントやデザイナなども含みます。ドメインモデルは各モデル間に関連を持たせます。したがって、それぞれのオブジェクトがどんな位置にあるのかが視覚的に解る様になります。これは用語集とするという点とも重複しますが、組織化することで、同じ用語を使っている筈なのに会話がどうも噛み合わなかったりといった事が起こりにくくなります。
ドメインクラスの抽出
ドメインクラス（ドメインオブジェクト）は、問題領域に含まれる現実世界のオブジェクトを抽出することで現れてきます。ここで言う問題領域とはソフトウェアの要件と考えて良いでしょう。問題領域には性能要件やインターフェイスの見栄えなども含まれますが、ドメインクラスを抽出するときには商品、カテゴリのような実際に「もの」として表現できるものを中心に抽出していきます。最終的なクラス図には性能要件を満たす為のキャッシュクラスなどが含まれるかもしれませんが、現時点では考慮しません。
このドメインクラスの抽出で重要な事は、時間をかけすぎない事です。ICONIXでは設計は段階的に行う為、この時点でのドメインモデルは不完全なもの、という前提で作成します。実際にユースケースを書いていく中で今は見えなかったオブジェクトが見えてくるでしょうし、必要と思われていたオブジェクトが不要だったりすることもあります。なので、２時間を目安にそれ以上の議論は無意味としています。
ドメインモデル図
ドメインモデルは、クラス図に良く似たダイアグラムとして作成します。ドメインモデル図は設計を進めていく中でクラス図へと拡張されていくでしょう。
ドメインモデル図を作成することとクラス図を作成する事の違いはほとんどありませんが、ドメインモデルで使用するのはクラス名、関連、汎化、集約の４点のみです。属性・インターフェイスといった他のクラス図の要素は一切使いません。属性も使わないという点には違和感を感じるかもしれません。ですが、ドメインモデルを作成する目的は細かい設計を行う事ではなく、用語集を作り関係者のコミュニケーションを円滑にすることです。商品にはどんな属性が含まれるかという検討はユースケースを作成していく過程で行います。
*1:それでも数が多いときついです。
