勉強まとめ

1. Clean
Architecture
第Ⅴ部
アーキテクチャ Part1

2. 前回まとめ
- コンポーネント
- コンポーネントとはデプロイ単位のことである
- 優秀なコンポーネントは常に個別にデプロイができる状態を保っている
- コンポーネントの凝縮性
- 再利用・リリース等価の原則（ REP）
- 閉鎖性共通の原則（ CCP）
- 全再利用の原則（ CRP）
- コンポーネントの結合
- 非循環依存関係の原則（ ADP）
- 安定依存の原則（ SDP）
- 安定度・抽象度等価の原則（ SAP）

3. - アーキテクチャとは？
- 独立性
第Ⅴ部：アーキテクチャ Part1

4. 第1章：アーキテクチャとは？
- ソフトウェアアーキテクチャとはプログラマである
- コードを書かずより高いレベルの問題にフォーカスするというのは間違い
- 自分で課題を経験し、生産性を最大化する設計にチームを導いて行くための「形状」
- ソフトウェアシステムの開発・デプロイ・運用・保守を容易にすること

5. 第1章：アーキテクチャとは？
開発
- 開発が難しいソフトウェアシステムは健全である可能性が低い
- チームの構成が違えば、アーキテクチャの決定も異なる

6. 第1章：アーキテクチャとは？
デプロイ/運用/保守
- デプロイ
- デプロイのコストが高ければその分だけシステムの有用性は低下する
- 運用
- アーキテクチャが優れていれば、システムの運用方法は開発者が見ればすぐにわかる
- 保守
- 保守は最もコストがかかる
- 既存のシステムを掘り起こし意図しない欠陥を生み出す可能性
- つまり
- 優れたアーキテクトは、方針と詳細を区別して詳細の決定をできるだけ延期・留保できる

7. 第2章：独立性
- 優れたアーキテクチャは以下の事をサポートする
- システムのユースケース
- システムの運用
- システムの開発
- システムのデプロイ

8. 第2章：独立性
ユースケース/運用/開発/デプロイ
- ユースケース
- 「ユースケース」とはアーキテクチャがシステムの意図をサポートする
- 優れたアーキテクチャを備えたカートはアプリケーションのように見える
- アーキテクチャがシステムの振る舞いに大きな影響を与えることはない
- 運用
- 運用に対してのアーキテクチャは本質的な役割を果たす
- ユースケースに対しての処理能力をサポートしなければいけない
- 優れたアーキテクトであればこれらの決定を選択肢として残せる
- 開発
- アーキテクチャは開発環境のサポートでは非常に重要な役割
- それぞれのチーム行動を独立させるアーキテクチャシステムを持たせる
- デプロイ
- アーキテクチャはデプロイの手軽さの決定にも役割がある
- 目指すべきは、変更に依存しない「即時デプロイ」

9. 第2章：独立性
レイヤーの切り離し/ユースケースの切り離し
- レイヤーの切り離し
- ユーザーインターフェイスを変更する理由は、ビジネスルールを変更する理由とは別である
- ユースケースの UI部分とビジネスルールを分離する
- ビジネスルールの appに密接した部分とそうでない部分は分離する
- システムは切り離された水平レイヤーで分割されている
- ユースケースの切り離し
- ユースケースはシステムを分割する自然な方法
- 注文入力システムに注文を追加するユースケースは、削除するユースケースと、異なる理由と頻度
で変更されるので、分離する
- それぞれのユースケースは、 UIの一部/ビジネスルールの一部 /DB機能の一部を使用し、それらを
薄く垂直にユースケースとして分割する
- 変更する理由の違いでシステムの要素を切り離しておくと、古いユースケースに影響を与えずに新し
いユースケースを追加できる

10. 第2章：独立性
独立した開発/独立デプロイ/重複
- 独立した開発が可能
- コンポーネントが明確に切り離されていれば、チーム同士の干渉は緩和される
- ユースケースがお互いに切り離されていれば、注文追加にフォーカスしたチームが、注文削除に
フォーカスしたチームへ影響を与えることはない
- 独立デプロイの可能性
- レイヤーやユースケースが切り離されていれば、デプロイの柔軟性も高まる
- 重複
- 「本物の重複」と「偽物の重複」があり見極めが必要
- ポイントは「変更頻度と変更理由」
- DBのレコード構造がある画面のデータ構造と似ているケースは、ほぼ「偽物の重複」である

11. 第2章：独立性
切り離し方式のレベル
- ソースレベル
- あるモジュールに対する変更が、他のモジュールの変更や再コンパイルにつながらないよう、ソース
コードモジュール間の依存性を管理する (Gemなど)
- コンポーネントは全て同じアドレス空間で実行される
- コンポーネント間の通信は、単純な関数呼び出しを使用し、 PCのメモリに読み込まれた単一の実行
ファイルが存在する (モノリシック構造 )
- デプロイレベル
- あるモジュールのソースコードに対する変更が、他のモジュールの再ビルドや再デプロイにつながら
ないように、デプロイ可能な単位の依存性を管理する (jarファイル/DLLなど)
- 多くのコンポーネントは同じアドレス空間に存在し、通信には関数呼び出しを使用する
- 重要なのは、コンポーネントが単独でデプロイ可能な単位 (jarファイル/Gemファイルなど)に分割され
ていること
- サービスレベル
- 依存性をデータ構造のレベルまで下げ、ネットワークパケットだけで通信する
- 全ての実行単位は完全に独立している
- ソースやバイナリを変更してもお互いに影響を与えることはない (サービスやマイクロサービスなど )

12. 第Ⅳ部：Part1 まとめ
- アーキテクチャとは？
- コードを書かずより高いレベルの問題にフォーカスするというのは間違い
- ソフトウェアアーキテクチャとはプログラマである
- 自分で課題を経験し、生産性を最大化する設計にチームを導いて行くための「形状」
- ソフトウェアシステムの開発・デプロイ・運用・保守を容易にすること
- 独立性
- 優れたアーキテクチャは以下の事をサポートする
- システムのユースケース
- システムの運用
- システムの開発
- システムのデプロイ