ユースケース駆動開発実践ガイドまとめと感想

はじめに

• エリック・エヴァンスのドメイン駆動設計を読んだ流れで DDD について調べていたらどこかの発表スライドでユースケース駆動開発実践ガイドをおすすめしていたので読んでみた。
• 一度通して読んだので復習しながら簡単なまとめと感想を記録しておく。

感想

• ウォーターフォール的なちゃんと設計ドキュメントを作ってから実装する、みたいな流れで開発をしたことがなかったので勉強になったし、ユースケースの作り方なんかはためになった
• これをそのまま実践するかというとしないと思うが、選択肢として堅いやり方を知っておきながら柔らかいやり方と使い分けていけるようになれればいいかなと思う

簡単なまとめ

• 全体を通して ICONIX（アイコニクス）プロセスという手法を使ったソフトウェア開発について書かれている
• ざっくりまとめると、要求を、ドメインモデル、ユースケース、ロバストネス図、シーケンス図、コード、と変換していくことで、要求漏れがなく手戻りが少ない開発ができる、みたいなことだと理解
• 以下各章ごとに順にまとめ

第1章 ICONIXプロセス

• 全体の大まかなまとめ
• 全部読んでからならここだけ読めばなんとなく復習できるかも

第2章 ドメインモデリング

• 静的モデルを一番初めに定義しておき、後の工程で曖昧さのない用語を利用する

感想

• エリック・エヴァンス本で言うユビキタス言語のことか
• エリック・エヴァンス本でドメインモデルというと図のことではなく振る舞いなども含めた概念を指すと思うので同じ言葉だが別のものを指しているはず

第3章 ユースケースモデリング

• 要求からユースケースを作っていく
• ユースケースとは「AはBをする、次にCはDをする」という叙述的なものになる
  • ユーザーがログインする場合のユースケースの例は「システムはログイン画面を表示する。ユーザーはユーザー名とパスワードを入力してログインボタンを押す。システムはユーザー名とパスワードをチェックする。ユーザーはシステムにログインする。」といったもの
• ユースケースは基本コース（正常系）と代替コース（異常系）すべてを網羅すること
• ユビキタス言語を使用して記述されていること
• 「ログイン画面を表示する」というようにGUIの具体的なパーツ名を使用して記述されていること
• 必要であればドメインモデルを更新する

3つの魔法の質問

• ユースケースを書くときには、「何が起きるか？」「そして何が起きるか？」「他にどのようなことが起きそうか？」という質問を繰り返して正常系異常系すべてのケースをあぶり出していく

第4章 要求レビュー

• ドメインモデルとユースケースが要求を満たしているか顧客と共にレビューを行う
• 必要なら紙芝居やモックやプロトタイプを作って説明を行う

第5章 ロバストネス分析

• ユースケースをロバストネス図に変換する
• ロバストネス図とはバウンダリオブジェクト（UIオブジェクト・名詞）とエンティティオブジェクト（ドメインオブジェクト・名詞）とコントローラ（メッセージ・動詞）でユースケースを表した図
• 名詞は動詞としかつながらない、動詞は動詞でも名詞でもつながる
• 必要であればユースケースを更新する

感想

• ロバストネス図を作ることで予備的な設計が行われ、UIやドメインや処理の不足や用語のブレなどがあらかじめ浮き彫りになってくる
• 最近 twitter で流れてきた、先の工程に進むと前の工程のアラが見えてくる法則を逆に利用してはやめに先の工程に進んでミスを潰していくという戦術なのかも
• オブジェクトでもコントローラでもない、間の線に書かれた文字の意味がわからない
  • なんとなくユーザーの振る舞いは線上に書いている気がする
  • ユーザーの振る舞いでもコントローラになっているものもある
  • 粒度の問題？
  • たぶん説明がないのでロバストネス図について理解が曖昧になっている

第6章 予備設計レビュー

• ユースケースとロバストネス図を顧客とともにレビューする
• それぞれ辻褄が合っているかの確認やドメイン要素やUIの要素の名前の確認などを行う

第7章 テクニカルアーキテクチャ

• ロバストネス分析中から全体的なシステム構成を考えていく
• 要求に基づいてアーキテクチャを選定しステークホルダーに説明を行う
• 選択について説明ができなければならない
• スケーラビリティ・セキュリティ・可用性・国際化・地域化・テスト容易性などに考慮すること
• アーキテクチャが正しいと信じる勇気とプロジェクトを通じてアーキテクチャの決定を推進する強さを持ちなさい

第8章 シーケンス図

• ロバストネス図をシーケンス図に変換する
• 正常系も異常系も同じシーケンス図上に記述する
• ロバストネス図上では各コントローラについて誰が主体になって行っているかが記述されていないので、シーケンス図を使って処理の主体をはっきりさせてオブジェクトとメソッドを定義していく
• 活性区間（線上の長方形、オブジェクトのライフタイムを表す）は利用しない
• 必要であればロバストネス図を更新する

第9章 詳細設計レビュー

• シーケンス図を開発者のみでレビューする
• シーケンス図とユースケースの割り当てができてるかや、適切な属性と操作が割り当てられているかなどを確認する

第10章 実装

• ここから具体的に Spring Framework を使って具体的に実装していく
• 汎用的に使えそうな内容としては、設計をそのまま実装しなさい、コーディング中につまったら設計から見直しなさい、設計とコードを常に動悸させなさい、コメントを書きすぎてはいけません、正常系だけでなく異常系も書くのです

感想

• ここから先は Spring Framework についての具体的な話になっており流し読みしたくらいなので省略