はじめに
先日エヴァンス本を読み終わり、最近『ユースケース駆動開発実践ガイド』を読み始めました。 この本を選んだ理由としては下記の2点です。
- エヴァンス本を読んで、ドメインモデルとコードを一致させることが大事だということがわかったが、そもそも適切なモデルの作り方がわからない
- ドメインモデル・ユースケース図を元に実装するというのがどういうことなのか、実際に体験しながら学びたい
やはり読みっぱなしだと頭に残らないので、今回も自分なりにまとめたり、疑問点を書き出しながら読み進めていきます。 あくまで個人の学習メモなので、わかりづらいところ、誤っているところがあると思います。
第1章 ICONIXプロセス
ICONIXプロセスはユースケースを元に、ドメインモデリングから実装・テストまでの一連の開発の流れを示すもの。
→ よって、ICONIXプロセスはアジャイルPJによく適合する
ICONIXプロセスは下記の流れで作業が進められる。(詳細は個々の章で説明される)
第2章 ドメインモデリング
ドメインモデルとは
プロジェクトで使われる単語について、単語間の関係をグラフィカルに表現したもの。プロジェクトの単語集
なぜユースケースの前にドメインモデルなのか
- ユースケースは抽象的に書かれるべきと言われることが多い
- しかし、ユースケースから分析と設計の結果を導き出したいのであれば、ユースケースは現実に基づき、設計するシステムに近いものであるべき(オブジェクトモデルの用語を使って書かれるべき)
- よって、ユースケースを書く前にドメインモデルを書く必要がある
ドメインモデリングのガイドライン
- 現実世界のオブジェクトに焦点を合わせる
- 汎化・集約関係を使う
- 最初のドメインモデリングにかかえる時間は2時間に限定する
- 最初のドメインモデルは不完全でいい
- 問題領域中の主要な概念を中心にクラスを構成する
- ドメインモデルデータモデルは別物
- RDBのテーブルは、様々なものとの関係を持つ
- それに対してクラスは、データと振る舞いが比較的小さくまとまっていることが良い設計の条件になる
- オブジェクトとデータベースのテーブルを混同してはいけない
- オブジェクトは、何かのインスタンスを表したもの
- テーブルは、何かの集合を表したもの
- ドメインモデルをプロジェクトの用語集として使う
- ユースケースを書く前にドメインモデルを書く
- 最終的なクラス図がドメインモデルと合致することは期待しない
- ドメインモデルにはGUI固有の部品クラスを配置しない
- ドメインモデルは純粋に問題領域に焦点を当てるべき
高レベルの要求から最初のドメインモデルを引き出す
ドメインモデルを1から作成する時は、「システムは～しなければならない」という形式の、抽象度の高い要求からスタートすることが多い
- そのような要求から名詞・名詞句を抽出する形で、ドメインクラスを抽出していく作業を行う
- 抽出した名詞リストから、似たような単語を識別し、除去(一つの単語に統一)してしまう
- 残った単語の内、外部システムはアクターとして扱う
- あるクラスが別のクラスの「一種」なのであれば、それは汎化関係で表す
→ 上記の作業を行うことで、最初のドメインクラスのプロトタイプが出来上がる
感想
- エヴァンス本と比べるとものすごい読みやすい。
- 今まで、「ユースケースから正確にコードを書き起こすのって可能なの...？」とぼんやり疑問に思っていたが、その答えがこの本で見つかりそう。
- 何もない状態からのドメインモデルの作り方がすごい理解しやすかった。
