要するに分かりにくい。チェックの必要をなくす。チェックのような分岐処理を記述することもできる。よって包み込んでしまうだけでは?そうかもしれない。提供する振る舞い(一般的に何も実行しないという振る舞い)が正しい振る舞いでないのであれば、分岐処理は必要である。何もしないでスルーしてもよいケースなんてそんなないでしょ?プレースホルダ的な機能を用意しておくケースはいろいろある。あるピアへの接続が完了するまではイベント発生しても何もしないとか、イベントに対して何らかの振る舞いを後付けで割り当てるケースなど。導入するというのは、本質的な使い方ではない。導入したところでそのシーケンスが必要なくなるわけではない。(給与システムのケーススタディ:最初のイテレーション)データベースは実装の詳細にすぎないので、データベースについて考えるのはできるだけ後回しにすべき。ユーザーストーリーの概念にそっくり。ユースケースはユーザーストーリーをもう少し詳細にしたものだと考えればよい。ユースケースを使った落とし込みは、現在のイテレーションで実装する必要のあるユーザーストーリーについてだけ行うべき。各イテレーションの最初で、チーム全員がホワイトボードの前で、選択されたユースケースの簡単な設計議論を行うのは「考えるプロセスを始める」ためであり、設計の詳細を詰めるためではない。のめり込んでしまうのは危険である。教えてくれなかった設計の問題点を教えてくれる。ダイアグラムは役立つツールだが、コードからのフィードバックなしに依存しきってしまうのは危険だ。フィードバックなしに設計を進めると必ずエラーが発生する。エラーを防ぐには、テストケースやコードを走らせることでフィードバックを得ること。データベースを設計や実装の主要部分とみなすべきではない。データベースに対する考察は最後まで残し、詳細設計として扱うべきである。することで、データの保存方法や、テストのメカニズムをどう作るかに関して色々な選択肢を残しておける。(パッケージ設計の原則)大きなアプリケーションを体系化するにはクラスだけでなく、もっと大きな単位のパッケージが必要になる。クラスをとりまとめるコンテナとしてパッケージを扱える。Principle)再利用の単位とリリースの単位は等価になる。再利用されるものはリリースされて、そのパッケージにリリース番号を与えてトラッキング可能でなければならない。パッケージ内のクラスはすべて再利用可能なものか、すべて再利用できないものかのどちらかにすべき。Principle)パッケージに含まれるクラスはすべて一緒に再利用される。一緒に使われる傾向のあるクラスは同じパッケージに属す。コンテナとイテレータなど。逆に、一緒に使われる傾向のないクラスは同じパッケージに入れるべきではない。ある新しいクラスを使おうとしてパッケージを新しいものに置き換えると、そのパッケージ内のクラスを利用しているコードをすべて再評価しなければならない。Principle)パッケージに含まれるクラスは、みな同じ種類の変更に対して閉じているべきである。すれば、仕様変更があってもその影響を受けるパッケージを最小限にできる。Principle)パッケージ依存グラフに循環を持ち込んではいけない。パッケージの依存グラフの矢印を辿っていったときに、最初のパッケージに戻ってきてはいけない。矢印を下向きに書くと、上向きの矢印が出てきたときに依存関係が循環してしまっていることがすぐに分かる。なっていれば、新しいパッケージのリリースによる影響範囲を絞り込みやすい。矢印をただ逆に辿ればよいだけ。依存グラフが循環すると、ほとんどのパッケージを同時にビルド、リリースしないといけなくなる。パッケージ依存構造は、アプリケーションの作成の過程で変化していくものなので、常に依存構造に循環が起きていないか見張っておかなければならない。パッケージ依存ダイアグラムはビルド方法を示すマップであり、アプリケーションの機能の概要を示すことはほとんどない。クラスを作る前にパッケージダイアグラムを作ろうとするのは間違い。確実に依存関係が循環することになる。Principle)安定する方向に依存せよ。パッケージの不安程度は、それが依存するパッケージの不安程度より大きくあるべきだ。不安定なパッケージを常に上に描くようにするとよい。違反していることが分かる。Principle)パッケージの抽象度と安定度は同程度でなければならない。パッケージの安定度が高いということは、それ相応の抽象クラスで構成されているべきということ。このバランスが崩れると、無意味なパッケージ、苦痛を伴うパッケージが生まれることになる。する部分がコードが含まれていれば、そのクラスに依存してしまう。パターンは、抽象インタフェースのみで具象クラスを作成することを可能にする。実装を自由に入れ替えられることがあげられる。抽象化しておけば、オブジェクトのインスタンス化方法を簡単に変更できる。パターンを、テスト用のモックオブジェクトを作成するために使うこともできる。参照をセットできるようになる。本物のコードに一切手をつけずにテスト用の振る舞いをさせることができる。パターンを適用しなければならなくなる。パターンを適用するとよい。使って永続性のあるオブジェクトを作るために必要になる。ユニットテストのために、オブジェクトを生成するオブジェクトをだまさないといけない場合。詳細部分が下の方に配置されている。抽象化された部分がより下に配置されている。再利用の単位はパッケージ単位になる。あるからで、互いに強く依存しているから。これはパッケージ分割のひとつの指標になる。パッケージ分割はシンプルなところから始めて、徐々に複雑にしていくのがよい。再利用されないものや、変更の少ないものまでパッケージ分割するのはやりすぎ。パターンによって下げることができる。通してインスタンス化するようにすればよい。機能面を軸にパッケージ分割するよりも、トランザクションを軸にパッケージ分割する方がずっと意味がある。