KDOC 678: 『Clean Architecture』

• 作成
  • 2026-10-17 貴島
• レビュー
  • 2026-10-17 貴島

『Clean Architecture 達人に学ぶソフトウェアの構造と設計』は、コードをどう組み合わせるかというアーキテクチャについての本である。

• 構造化、関数型、オブジェクト指向…プログラミングパラダイムは、どれも制限を課すものである
• オブジェクト指向のもっとも有益な特徴はポリモーフィズムである。ソースコードの依存関係を実行順序と関係なくできる。ビジネスロジックが最上位にあり、下位にライブラリやデータベースを置き、これらは交換可能である。実行順序とは逆だ
• プラグインアーキテクチャは、上位レベルの方針を含んだモジュールを下位レベルの詳細を含んだモジュールから独立させること。下位レベルの詳細はプラグインモジュールとなり、上位レベルの方針を含んだモジュールとは独立して、デプロイおよび開発することが可能となる
• 単一責任原則(SRP)の失敗例: Employeeクラスに、経理、人事部門、データベース管理者の3つの部門の責務が入っているようなとき。
  • つまり、アクターの異なるコードは分割すべきということ
• オープン・クローズドの原則(OCP): ソフトウェアの振る舞いは、既存の成果物を変更せず拡張できるようにすべきである。
  • ローグライクチュートリアルがまさにそんな感じだった。機能追加で既存の箇所をいじる必要はなく、独立している
  • ちょっとした拡張のために大量の書き換えが必要になるようなら、そのソフトウェアシステムのアーキテクトは大失敗への道を突き進んでいる
• 依存性逆転の法則: ソースコードは具象に依存するべきではない。変化しやすい具象クラスを参照しない、継承しない。重要な部分が、重要でない部分に依存しないように設計すべき
• 再利用・リリース等価の原則: 同じタイミングで変更されることが多いクラスはひとつにまとめる
• 閉鎖性共通の原則: 同じ理由、同じタイミングで変更されるクラスをコンポーネントにまとめること。変更の理由やタイミングが異なるクラスは、別のコンポーネントに分けること
• 全再利用の原則: コンポーネントのユーザに対して、実際には使わないものへの依存を強要してはいけない
• 安定依存の原則: 安定度の高い方向に依存する
• 安定度・抽象度等価の原則: コンポーネントの抽象度は、その安定度と同程度でなければならない。安定度の高いコンポーネントは抽象度も高くあるべき
• 優れたアーキテクトは、方針と詳細を慎重に区別して、方針が詳細を把握することなく、決して依存することがないように、両者を切り離す
• アーキテクチャがサポートしなければいけないこと:
  • システムのユースケース
  • システムの運用
  • システムの開発
  • システムのデプロイ
• 注文入力システムに注文を追加するユースケースは、注文を削除するユースケースと比べると、明らかに異なる頻度と理由で変更される
• 優れたアーキテクトは、システムの詳細の決定を従属的かつ遅延可能なものにする

なし。