この本に期待すること
- Clean Architecture を説明できるようになりたい
- 今業務で扱っているプロダクトが Clean Architecture を取り入れている部分とそうでない部分、メリデメを理解したい
- フロントエンドにも適用できる？
要約
1 章 設計とアーキテクチャ p.33 – p.40
設計の目的 = ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するために必要な人材を最小限に抑えることである。
- 開発者が増えても、リリース頻度やコード数が増えなければ崩壊のサイン
- 市場に投入するスピードを言い訳に、クリーンでないコードを書いた結果、遅くなり競合に抜かれる
- TDD は早い
2 章 2 つの価値のお話 p.41 – p.45
振る舞い
ステークホルダーのマシンが要件を満たせるように、プログラマはコードを書くことになる。
多くのプログラマは、それが自分たちの仕事だと思っている。マシンが要件を満たせるようにして、バグがあれば修正する。それが仕事だと信じている
構造
ステークホルダーが機能を変更したいと思えば、その変更は簡単にできるようになっておくべきだ。変更の難易度は、変更の形状でなく、変更のスコープに比例しなければいけない。
7-10 章
オープン・クローズドの原則
ソフトウェアを変更しやすくするために、既存のコードの変更よりも新しいコードの追加によって、システムの振る舞いを変更できるように設計すべきである
リスコフの置換原則
交換可能なパーツを使ってソフトウェアシステムを構築するなら、個々のパーツが交換可能となるような契約に従わなければいけない
20 章 ビジネスルール p.189 – p.193
ビジネスマネーを生み出したり節約したりするルールのこと たとえば、銀行がローンに N%の利子を付けているとすると、それは銀行のお金を生むためのビジネスルールになる 利子をコンピュータで計算しようと、そろばんで計算しようと、まったく関係はない。
ビジネスデータ
ローンであれば、貸付金残高、金利、支払いスケジュールなど
最重要ビジネスルールと最重要ビジネスデータは密接に結び付いているため、オブジェクトの有力な候補になる。こうしたオブジェクトのことをエンティティと呼ぶ
ユースケース
自動化されたシステムを使用する方法。ユーザーから提供された入力、ユーザーに戻す出力、出力を生成する処理ステップなどを規定している アプリケーション固有のビジネスルールが含まれている
例: 候補者の与信スコアが 500 以上あることを確認するまで、ローンの支払い見積りを提示しないと決めているとしよう その場合、 連絡先情報画面がすべて入力され、値がきちんと検証され、与信スコアが基準値を超えていることが確認できるまでは、支払い見積りの画面に進まないようにシステムを設定する
22 章 クリーンアーキテクチャ p.199- p.205
右下に、円の境界線をどのように越えるべきかの例を用意した。コントローラー とプレゼンターは、次のレイヤーのユースケースと通信している。制御の流れに注目してほし い。コントローラーから始まり、ユースケースを経由して、最後にプレゼンターで実行されて いる。ソースコードの依存関係にも注目してほしい。それぞれが内側のユースケースに向かっ ていることがわかる。 こうした明らかな対立は、通常は依存関係逆転の原則(DIP)を使って解消する。Java のよ うな言語では、インターフェイスや継承を整理して、境界線を越えたところでソースコードの 依存関係が制御の流れと逆転するようにする。たとえば、ユースケースからプレゼンターを呼び出す必要があるとしよう。依存性のルール に違反するため、直接呼び出すことはできない。円の外側にある名前は、円の内側から触れる ことはできないからだ。したがって、ユースケースから円の内側にあるインターフェイス(図 22-1 の「ユースケース出力ポート」)を呼び出すようにして、円の外側にあるプレゼンターが インターフェイスを実装することになる。
エンティティ
エンティティは、企業全体の最重要ビジネスルールをカプセル化したものだ。エンティティは、メソッドを持ったオブジェクトでも、データ構造と関数でも構わない
インターフェイスアダプター
モデルは、コントローラーからユースケースに渡され、ユースケースからプレゼンターとビューに戻されるデータ構造にすぎない
プレゼンター
ビュー
コントローラー
後で調べる
- プレゼンター、ビュー、コントローラー
- この書籍で言う MVC の確認。Spring MVC が言及されている？