ドメインについて（５）

FDDはDe Lucaによって開発され、シンガポールプロジェクトで彼がCoadと作業している時に修正された。ますます短期化するビジネスライフサイクルへのレスポンスタイムに取り組むためには不要な工程を切り捨てる必要があった。

Coadは云った。「10年前、私たちの一人が110頁のプロセスを大規模開発チームのために作成した。私は彼のプロセスの各頁が価値あるものだと弁護したがチームメンバーは最後の4頁の要約を常に見て残りは無視した」

De Lucaは云った。「プロジェクトではクライアント、開発者、管理者の全てがFDDを気に入っていた。」

FDDでは2週間のインターバルで機能が納品される。頻繁に発生するこの納品はクライアントにとって意味のあるマイルストーンにより計画される。

FDDプロセスはイテレーティブなアジャイル開発の中でもっともシンプルな手法の一つである。ワークフローはこうだ。

プロセス1が特に重要だ。ここではチーフアーキテクトがモデラーとドメインエキスパートで構成されるチームを主導する。ドメインエキスパートは要件を提供し、モデラーはこれをドメインモデルに落とす。それが役目だ。De Lucaはこのプロセス1の10%の時間が開発に於いて最も価値がある時間とした。

短いレスポンスタイムが要求されるシステム開発でFDDは要件定義を行わない代わりにドメイン設計を行う。つまり設計工程に新たな作業を導入する。これにより設計工程は複雑になるし様々な対立も発生する。これは課題のひとつだが、その代わりに得られる開発短期化の魅力は課題を鑑みてもお釣りが来る。

オブジェクト指向モデラー対データベースモデラー・・これは思想の対立と云える。両者の対立は管理者や他の開発者も巻き込む。このようなことが起きないように管理者はメンバー選定に注意を払うべきだろう。
プログラマ対モデラー・・これはプログラマがドメインを無視するという意味である。何の対策もしなければプログラマは自分が欲しい機能を作成する。ドメインを利用しなくてもいいなら利用しない。結果、この対立の勝者はプログラマとなる。この対立を防ぐためにはプログラマに分かり易いガイド（標準）の作成と監査が必要だ。プログラマを設計者に置き換えた対立もある。
管理者対モデラー・・作業量の多さ、高頻度の要件変更、情報収集の機会のなさなどが対立の原因である。これはプロセス1で解決するより他ない。