DDD / Exploration Teams

探索部隊 (p.322) †

要約 †

• 不満の要因がなんであれ、次のステップは、モデルが明確にそして自然に物事を伝えるようにするための改善策を探ること。これはすぐに済むこともあれば、時間と人が必要になることもある。

• 探索部隊による問題追求
  • 言いだしっぺはこの手の問題を考えるのが得意な開発者やドメインのことを良く知っている開発者、優れたモデリング技術をもつ開発者や場合によってはドメイン・エキスパートを集めて探索部隊を結成する。
  • 会議室か喫茶店にでも行って、30分〜1時間30分位ブレインストーミングをする。
    • UMLを書く。
    • いろんなオブジェクトを使って、シナリオのウォークスルーを行う。
    • この問題の責任者がモデルを理解し使えると思えるかどうかを確認する。
  • 何かしら見出すことができれば、「めでたしめでたし」で、席に戻ってコーディングをする。
  • もしくは、２、３日じっくり考えることにして、別の作業を続ける。
    • 後でもう一度ブレインストーミングを行う。
    • その時にはなんらかの結論にたどり着く（はず）。
    • 席に戻って新しいデザインをコーディングする。

• 問題追求プロセスを生産的にするためのキー
  • 自己決定力
  • 範囲を限定し、必要に応じて寝かす
  • UBIQUITOUS LAGUAGEの実践

• まとめ
  • 以前の章で紹介した、開発者とドメイン・エキスパートの対話が好例であるように、完璧な("full-blown")ブレインストーミングはダイナミックで流動的で、信じられないほど生産的なのだ。

担当者のつぶやき †

• 細かいところですが、p.322、Exploration Teams第二段落のl.8がいまいち不明瞭です・・・
  • They make sure the subject matter expert understands the model and finds it useful.
  • 次のページにも出てきますが、the subject matter expertって誰のことを指すのでしょうか？単数形であるところを見ると、単に詳しい人ではなく、明確な役割を持った誰かのようですが。。。

みんなの突っ込み †

まとめ (議事録) †