ユースケース駆動開発実践ガイド
https://gyazo.com/5fe678481173c06f85e2b8b4eca94b37
#読書
Classiでアーキテクトをしているaerealさんにすすめられて読んだ
すすめられた文脈は、PdMやステークホルダーに伝わりやすい図解や文書のよくあるフォーマットとして、ロバストネス図などを使うと良さそうというサジェスト
書籍自身は要件定義として、ドメインモデリング、そしてユースケースの叙述的な言語化（余すことなく）、ユースケースからロバストネス分析と静的モデルの見直し、そして叙述的自然言語からシーケンス図に起こして静的モデルに振る舞いを付けていく作業を経て詳細設計に入り、Springを使って実際に実装する + TDD のような構成になっている（要求
設計に至る以前の要求を導出しどう設計につなげるかの妙が非常に分かりやすいアプローチだと思った
と同時にステップが重厚なのでこれをもっと手早くやる方法についても身につけると良さそうではある
以下付箋抜粋
要求分析：ドメインモデリング
不足したオブは、ユースケースやロバストネス図を作成していく過程で見つけ出すことができます。ユースケース駆動型プロセスではドメインモデルは不完全だと仮定しており、何が不足しているかを見つける仕組みを提供しています。
この段階ではスカスカで頼りないドメインモデルでもかまわず2時間以上かけないとある
文法的な検査でも悩まなくてよい、とある
曖昧な要求が敵であるとすれば、ドメインモデルは最初の防衛線です。「特定の課題にだけは詳しい専門家」はよく名前を曖昧に使いますが、それはプロジェクトにとって極めて有害です。ドメインモデルは、問題領域を説明するときに一貫した意味を確保させるための用語集として活用できます。
特定の課題に詳しい人の名付けのまま進めると発生する問題はなんだろう
漸進的な反復と洗練による継続的な改善
ドメインモデルはこのあと静的モデルとなり振る舞いをもったクラス図になりえる
外部システムはアクター
要求分析：ユースケースモデリング
ユースケースは「ユーザーはこのシステムで何をしたいのか？」「ユーザー何を得たいのか？」といった、基本的な疑問に答える助けとなります。
システムの使い方
2段落ルール
プラス、基本コース・代替コース
アクターとユースケース図でユースケースを組織化
ユースケースは叙述的に記述
イベントとのその応答の流れ、ユーザーとシステムの対話を両方
ユースケースモデリングは外側から内側へのアプローチ
ユースケースは実行時の振る舞いの仕様
オブジェクトモデルの使い方
オブジェクトモデルの言葉を使ってユースケースを書く
名詞-名詞-動詞の構造に従ってユースケースを書く
e.g. システムは + ユーザに + 書籍一覧を表示する
バウンダリクラス（主に画面）の名前を書く
要求レビュー
要求のトレーサビリティとは、すべて『恐怖』にかかる問題だ
要求をなぜ追跡したがるのかという問いに対するUncle Bobの言葉
顧客の要求をユースケース上で追跡し続ける
要求分析：ロバストネス分析
ユースケースに対する健全性チェック
叙述的なユースケースに貼り付けてスタートする
ユースケースを1文ずつ見てロバストネス図を作成し並行して記述も修正する
アクター、バウンダリー、エンティティを中心にコントローラでつなぐ
つなぎ込みは制限がある
e.g. 正）アクター -> バウンダリー -> コントローラ -> エンティティ -> バウンダリー
バウンダリー -> バウンダリーはありえず、アクター -> エンティティもありえない、エンティティ -> エンティティもない
最初のドメインモデリングは2時間に限定して取り組んだのですから、当然ながら取りこぼしたドメインクラスがあるかもしれません。(略)そのクラスをドメインモデルに追加してください
ユースケース駆動開発実践ガイド#657e60a69929f00000bd190d オブジェクトの発見
悩む場合は…
たんにユースケース記述の最初の文から初めて、読んだままを描く
記述の出だしがユースケースのスタートではないことにも気づく
予備設計レビュー
目標はシステムの振る舞い完全に理解して明示すること
簡単な手順
図がユースケースに合致しているか
図がロバストネス分析規則に従っているか
図がユースケースの論理的な流れに注力しているか
図に動作に必要となる代替コースがあるか
図が詳細設計に踏み込んでないか
付箋節参照：テクニカルアーキテクトの義務とはなにか？
詳細設計：シーケンス図
どの操作がどのクラスに割り当てられるかの決定
1. ユースケース記述を貼り付ける
2. ロバストネス図からエンティティをコピー
3. ロバストネス図からバウンダリとアクターをコピー
バウンダリクラスは基本的に画面（HTMLなど）を指し真のオブジェクトではないとするならエンティティに振る舞いを当てるべき
4. クラスに操作を割り当て
ユースケース記述をもとにロバストネス図をチェックしたことを忘れずに。ロバストネス図をシーケンス図に対するチェックリストとして使うということは、(略) 設計が要求に合致していることが保証できます
オブジェクトが責務を果たすためには選択肢が3つ
自分ですべての作業をおこなう
作業の一部を行ってもらうようほかのオブジェクトに支援をもとめる
ヘルパーオブジェクトに全リクエストを移譲する
シーケンス図に実装の詳細をあらわすクラスが出てきたとしても、ここでは解決空間（solution space）なので問題なし。ドメインモデルに示されているのは問題空間（problem space）
詳細設計を行う間に2つの空間は収斂していきます。シーケンス図の作成中に静的モデルを更新することによって、問題空間と解決空間を収斂させていくのです。
シーケンス図には活性区間を表示しないようにする（煩雑になる
付箋コラム参照：小さなクラスの群れ p269 ドメインモデル貧血症に絡む話題
/kawasima/ドメインモデル貧血症
p345 入力用バリデータなどの検証用ロジックはデータが存在するところに置くべき
安定した抽象化
コードの主要な抽象化は、問題領域が語る真実に基づきます。というのも問題領域こそ最終的には最も安定するものだからです。
コードレビュー
コードレビューだけではなく、モデルの更新セッションでもある
ここまでで見落としがなかったのか、分析まで遡ることもありえる
設計駆動テスト
テストにおける失敗TOP10 付箋参照 p.408