Clean Architecture

1. ソフトウェアアーキテクチャは人的資源の最小化と生産性の最大化を目指す

ソフトウェアアーキテクチャの目標は、必要なシステムを構築および維持するために必要な人的資源を最小限に抑えることである。

アーキテクチャの決定は重要である。 良いアーキテクチャは、ソフトウェアシステムの開発、展開、および維持に必要な労力を減少させる。これにより、チームは独立して作業でき、変更の影響を最小限に抑え、システムが時間とともに進化することを可能にする。

良いアーキテクチャの主な側面:

• 関心の分離
• 依存関係の管理
• 実装詳細の抽象化
• 将来の変更に対応する柔軟性

これらの側面に焦点を当てることで、アーキテクトは理解しやすく、変更しやすく、拡張しやすいシステムを作成し、最終的には生産性の向上とシステムのライフタイムコストの削減を実現できる。

2. クリーンアーキテクチャはビジネスルールを外部の詳細から分離する

アプリケーションの中心はデータベースではない。また、使用しているフレームワークのいずれかでもない。アプリケーションの中心はそのユースケースである。

ビジネスルールが核心である。 クリーンアーキテクチャはコードを同心円状に整理し、ビジネスルールを中心に、実装の詳細を外側の層に配置する。この分離により、データベース、ユーザーインターフェース、フレームワークなどの外部要因の変更によってコアビジネスロジックが影響を受けないようにする。

クリーンアーキテクチャの主な層:

• エンティティ: 企業全体のビジネスルール
• ユースケース: アプリケーション固有のビジネスルール
• インターフェースアダプタ: ユースケースと外部エージェンシー間のデータ変換
• フレームワークとドライバ: 外部ツールと技術

この構造に従うことで、開発者は以下のようなシステムを作成できる:

• 変更に柔軟に対応できる
• テストと保守が容易
• 特定の技術やフレームワークに依存しない

3. SOLID原則は柔軟で保守可能なシステムの作成を導く

SOLID原則は、関数とデータ構造をクラスにどのように配置し、それらのクラスをどのように相互接続するかを教えてくれる。

SOLIDはモジュール性を強化する。 これらの5つの原則は、理解しやすく、柔軟で保守可能なソフトウェアシステムを作成するためのガイドラインを提供する。これにより、変更に強く、拡張しやすいコードを設計するのに役立つ。

SOLID原則は次の通り:

• 単一責任の原則: クラスは変更の理由を一つだけ持つべき
• 開放/閉鎖の原則: ソフトウェアエンティティは拡張に対して開かれているが、変更に対して閉じているべき
• リスコフの置換原則: スーパークラスのオブジェクトは、そのサブクラスのオブジェクトで置き換え可能でなければならない
• インターフェース分離の原則: 多くのクライアント固有のインターフェースは、一つの汎用インターフェースよりも良い
• 依存性逆転の原則: 高レベルモジュールは低レベルモジュールに依存すべきでなく、両方が抽象に依存すべき

これらの原則を適用することで、開発者は変更要求に適応できる、より堅牢でスケーラブルなソフトウェアアーキテクチャを作成できる。

4. コンポーネントはクリーンアーキテクチャの構成要素である

コンポーネントはデプロイの単位であり、システムの一部としてデプロイ可能な最小のエンティティである。

モジュラー設計は柔軟性を可能にする。 クリーンアーキテクチャのコンポーネントは、独立してデプロイおよび開発可能なシステムの部分である。これらは関連する機能をカプセル化し、明確なインターフェースを持つため、システムの保守と変更が容易になる。

よく設計されたコンポーネントの主な特徴:

• 高い凝集性: 関連する機能が一緒にグループ化されている
• 低い結合性: コンポーネント間の依存関係が最小限
• 明確なインターフェース: 明確に定義された相互作用方法
• 独立したデプロイ可能性: 他のシステム部分に影響を与えずに更新または置換可能

システムをコンポーネントに整理することで、アーキテクトは以下を実現できる:

• 異なるチームによる並行開発を促進
• テストとデバッグが容易
• システムの段階的な更新と改善を可能にする
• システム全体のスケーラビリティと保守性を向上

5. 境界はコアビジネスロジックを定義し保護する

各アーキテクチャの境界には、どこかにHumble Objectパターンが潜んでいる可能性が高い。

境界はコアを保護する。 クリーンアーキテクチャの境界は、特にビジネスロジックと実装の詳細の間で異なる関心領域を分離する。これらの境界は、コアビジネスルールが外部システムや技術の変更によって影響を受けないようにする。

アーキテクチャの境界の主な側面:

• 層間の相互作用を定義するインターフェースの使用
• 依存性逆転により依存関係が内向きになるようにする
• 境界を越えて情報を渡すためのデータ転送オブジェクトの使用
• テスト可能な動作をハードテストのコンポーネントから分離するHumble Objectの使用

明確な境界を確立することで、アーキテクトは以下を実現できる:

• 外部システムや技術の変更の影響を最小限に抑える
• コアビジネスロジックのテストを容易にする
• 実装の詳細をコアシステムに影響を与えずに置換可能にする
• システム全体の柔軟性と適応性を向上

6. クリーンアーキテクチャはテスト駆動開発と独立したデプロイを促進する

良いアーキテクチャは、変更が必要なすべての方法でシステムを変更しやすくし、選択肢を開いたままにする。

テスト可能性と柔軟性が鍵である。 クリーンアーキテクチャは、システムをテストしやすく、独立してデプロイしやすくする実践を促進する。関心の分離と依存関係の管理により、コアビジネスロジックの単体テストが容易になり、システムの異なるコンポーネントを個別にデプロイできるようになる。

クリーンアーキテクチャのテストとデプロイの利点:

• コアビジネスルールはUI、データベース、外部依存関係なしでテスト可能
• 異なるコンポーネントを独立してデプロイでき、更新が容易
• システムの一部の変更が他の部分に与える影響が最小限
• 新機能を追加する際の既存機能の破損リスクが低減

これらの特性により、以下が実現される:

• 開発サイクルの短縮
• デプロイのリスクの低減
• システムの信頼性の向上
• 新技術の採用や既存技術の変更に対する柔軟性の向上

7. フレームワークとデータベースは実装の詳細であり、アーキテクチャの要素ではない

フレームワークは使用するツールであり、従うべきアーキテクチャではない。

コアロジックはフレームワークに依存しないべきである。 クリーンアーキテクチャは、フレームワークとデータベースをコアビジネスロジックに影響を与えない外部の詳細として扱う。このアプローチにより、これらの外部要素を変更または更新してもシステムのコア機能に影響を与えない柔軟性が得られる。

フレームワークとデータベースの取り扱いに関する主要原則:

• それらをコアビジネスロジックへのプラグインとして扱う
• 依存性逆転を使用してコアロジックを独立させる
• データベース操作の抽象化を作成する
• フレームワークとデータベースの決定をできるだけ遅らせる

このアプローチの利点:

• フレームワークとデータベースの変更やアップグレードが容易
• コアビジネスロジックは外部の変更にもかかわらず安定
• ベンダーロックインの軽減
• コアシステムコンポーネントのテスト可能性の向上

8. ウェブはクリーンアーキテクチャにおける単なる配信メカニズムである

ウェブは配信メカニズムであり、アプリケーションアーキテクチャはそれをそのように扱うべきである。

ビジネスロジックは配信に依存しない。 クリーンアーキテクチャでは、ウェブはデータベースやフレームワークと同様に外部の詳細として扱われる。この視点により、コアビジネスロジックはウェブアプリケーション、デスクトップアプリ、APIなどの特定の配信メカニズムに依存しないようになる。

クリーンアーキテクチャにおけるウェブアプリケーションの主な考慮事項:

• ウェブ固有のコードをコアビジネスロジックから分離する
• ウェブフォーマットと内部データ構造を変換するためのインターフェースアダプタを使用する
• ウェブフレームワークをコアシステムへのプラグインとして扱う
• ユースケースをウェブ固有の懸念から独立させて設計する

このアプローチの利点:

• 異なる配信メカニズムにシステムを適応させやすい
• コアビジネスロジックを複数のプラットフォームで再利用可能
• ウェブ依存なしでビジネスルールのテストが簡単
• ウェブ技術の変更や更新に対する柔軟性の向上

9. クリーンな組み込みアーキテクチャはハードウェアの懸念をビジネスロジックから分離する

ソフトウェアは摩耗しないが、ハードウェアへの管理されていない依存関係によって内部から破壊される可能性がある。

ハードウェアの独立性は重要である。 クリーンな組み込みアーキテクチャは、組み込みシステムにクリーンアーキテクチャの原則を適用し、ハードウェア固有の懸念をコアビジネスロジックから分離する。この分離により、ハードウェアコンポーネントの更新が容易になり、ソフトウェアの移植性が向上する。

クリーンな組み込みアーキテクチャの主な要素:

• ハードウェア抽象化レイヤー（HAL）を使用してハードウェア固有のコードを隔離する
• デバイスに依存しないビジネスロジック
• ハードウェアとソフトウェアコンポーネント間の明確なインターフェース
• 依存性逆転を使用してハードウェア依存を管理する

このアプローチの組み込みシステムにおける利点:

• 新しいハードウェアプラットフォームへのソフトウェアの移植が容易
• ハードウェア依存なしでコアロジックのテストが簡単
• ハードウェアの変更がシステム全体に与える影響を軽減
• 組み込みソフトウェアの保守性と長寿命化の向上

10. マイクロサービスとサービス指向アーキテクチャはクリーンアーキテクチャの原則から利益を得ることができる

システムのアーキテクチャは、ソフトウェア要素を互いに分離し、一方の側が他方の側を知らないようにする境界によって定義される。

クリーンな原則はすべてのスケールに適用される。 クリーンアーキテクチャはモノリシックアプリケーションの文脈でよく議論されるが、その原則はマイクロサービスやサービス指向アーキテクチャにも効果的に適用できる。これらの原則は、個々のサービスの独立性とテスト可能性を維持しながら、分散システムの複雑さを管理するのに役立つ。

マイクロサービスにクリーンアーキテクチャを適用する:

• 各マイクロサービスを独自のクリーンアーキテクチャを持つ境界コンテキストとして扱う
• サービス間の通信のための明確なインターフェースを使用する
• サービス間の依存性逆転を適用する
• サービスの独立したデプロイ可能性を維持する

マイクロサービスにおけるクリーンアーキテクチャの利点:

• システム全体のモジュール性とスケーラビリティの向上
• 個々のサービスの理解と保守が容易
• サービスの進化と置換の柔軟性の向上
• サービス間の結合が減少し、より堅牢なシステムが実現

Last updated: July 26, 2024