#book #r2020  > ICONIX プロセスはユースケースとコードの間に存在する領域にフォーカスした、最小限かつ効率的なアプローチ  # ドメインモデル  - 最初のドメインモデリングで今後これは後ろの工程で更新されていく - Actorとクラスと has-a の関係を使ってモデルを作る - is-a の関係はドメインモデリングにおいてはあまり有用ではなく、設計の詳細に立ち入ってしまうことが多い - メソッド名やフィールドも必要不可欠の場合のみ追加する基本はいらない # ユースケースモデリングの理論 - ユースケースをパッケージに組織化する - UMLのパッケージ機能などで組織化して管理することが重要 - ユースケースには、ステレオタイプ (invokes, precedes, includes, extends など) があるがこれらは使わない方が伝わりやすい - 基本コース (晴れの日シナリオ) と 代替コース (雨の日シナリオ) を用意する - > 【基本コース】 - > 顧客は現在表示されてる書籍の「レビューを書く」ボタンをクリックし、システムは「レビューの記入」画面を表示する。顧客は書籍レビューを入力し、書籍評価を5つ星までの範囲で指定し、「送信」ボタンをクリックする。システムはレビューが短すぎたり長すぎたりしないか、書籍の評価が1~5の間となっているかどうかを確認する。そしてシステムは確認画面を表示し、レビューを追加するためにモデレータに送る。 - > - > 【代替コース】 - > ユーザーがログインしていない : ユーザーはまずログイン画面を表示し、ログインしてからもう一度「レビューの記入」画面に移動する。 - > - > ユーザーが書いたレビューが長すぎる (1MBより長い文章) : システムはレビューを拒絶し、レビューが拒絶された理由を説明するメッセージを表示する。 - > - > レビューが短すぎる (10文字未満の文章) : システムはレビューを拒絶する - ユースケースは能動的に書かれるべきである - 「する」で終わるとか - 「なぜ要求を追跡したがるのでしょうか？」-> 要求のトレーサビリティとは「恐怖」に関わる問題だ - 詳細は [Extreme Programming Refactored: The Case Against XP](https://link.springer.com/book/10.1007/978-1-4302-0810-5) # 感想 - 前半のユースケースの話やユースケースのモデリングは参考になった - 後半はやったらいいとは思うけれどあんまり今のweb開発とかの環境に合わなかったので流し読みした