Clean Architecture - 読書メモ 2

叫ぶアーキテクチャ

優れたアーキテクチャはユースケースを中心にしている

• フレームワーク・ツール・環境に依存しない
• 簡単にユースケースを把握できる

クリーンアーキテクチャ

クリーンアーキテクチャ

• フレームワーク非依存
• テスト可能
• UI非依存
• データベース非依存
• 外部エージェント非依存

依存性のルール

• ソースコードの依存性は、内側だけに向かっていかなければならない

エンティティ

• 企業全体の最重要ビジネスルール

ユースケース

• アプリケーション固有のビジネスルール

インターフェイスアダプター

• フォーマットを変換する
  • ユースケースやエンティティ用のフォーマット
  • データベースやウェブ用のフォーマット

フレームワーク・ドライバー

• フレームワークやデータベース

クリーンアーキテクチャ

プレゼンターとHumble Object

Humble Object パターン

• 「テストしにくい振る舞い」と「テストしやすい振る舞い」に分けるパターン
  • テストしにくい振る舞い
    • View・Database
    • シンプルに保っておく
  • テストしやすい振る舞い
    • Presenter・UseCase

部分的な境界

本格的なアーキテクチャの境界はコストが高い

• 多くの作業が必要であり保守も必要
• 優れたアーキテクトは、このような境界はコストが高すぎると判断する
  • 同時に、後で必要になるから境界を残しておきたいとも思う
    • YAGNIに違反する
    • 部分的な境界を実装

部分的な境界

• 最後のステップを省略
  • 独立してコンパイル・デプロイが可能な状態にしておくが、同じコンポーネントにまとめる
• 片方だけの境界
  • Strategyパターンを使い、片方だけの境界を作る
• Facade
  • Facadeパターンを使い、シンプルな境界を作る

片方だけの境界	Facade

サービス：あらゆる存在

サービスアーキテクチャ

• 「サービス思考アーキテクチャ」・「マイクロサービスアーキテクチャ」
  • サービスが互いに分離されているように見える → 正しくない
    • サービスは共有しているデータと強く結びついていて、間接的ではあるが相互に結びついている
  • サービスが開発・デプロイを独立させていように見える → 正しくない
    • 誤った分離により独立して開発・運用・デプロイできない
    • データや振る舞いが結びついている限り、開発・運用・デプロイには調整が必要となる

横断的関心事

• アーキテクチャの境界は
  • 正：サービスを横断することでコンポーネントに分割する
  • 誤：サービスとサービスの中間に位置する
• サービスは依存性のルールに従った内部コンポーネントのアーキテクチャと一緒に設計する必要がある

テスト境界

テスト容易性のための設計

• 脆弱なテストの問題
  • 共通のシステムコンポーネントを変更すると、何千や何百というテストが壊れる可能性がある
• テスト容易性の設計
  • 変化しやすいものに依存しない
    • GUIは変化しやすい → 脆弱である

テストAPI

• 変化しやすいものに依存しないようにするために
  • テストから使用できるAPIを作り、全てのビジネスルールを剣侠できるようにする

書籍

Clean Architecture 達人に学ぶソフトウェアの構造と設計