実践Clean Architecture ~FACADEパターン~

February 22, 2025

sattosh

Cover Image for 実践Clean Architecture ~FACADEパターン~

SOLID原則とは？

Clean Architecture は、ソフトウェアの設計と保守性を向上させるためのアプローチです。その中心にある SOLID 原則は、設計の柔軟性、再利用性、テスト容易性を実現するために考案されました。

Single Responsibility Principle (SRP):

各モジュールやクラスは、単一の責任のみを持つべきです。これにより、変更の影響範囲を限定し、理解しやすい設計となります。
Open/Closed Principle (OCP):

モジュールは拡張に対してはオープンであり、変更に対してはクローズドであるべきです。新機能は既存のコードに影響を与えずに追加できます。
Liskov Substitution Principle (LSP):

サブタイプは、スーパークラスと置き換え可能でなければなりません。これにより、継承を正しく使用し、予測可能な動作を保証します。
Interface Segregation Principle (ISP):

多機能なインターフェイスよりも、小さく具体的なインターフェイスを多数用意することで、クライアントが不要なメソッドに依存しないようにします。
Dependency Inversion Principle (DIP):

高レベルのモジュールは低レベルのモジュールに依存すべきではなく、両者とも抽象に依存するべきです。これにより、システム全体の柔軟性とモジュール性が向上します。

これらSOLID原則を踏まえることで、Clean Architecture はシステム全体の品質を高め、長期的な保守性を実現すると書籍で提唱されています。

この中でSRPの紹介の中で出てくるFacadeパターンの具体コードを踏まえて理解していこうかと思います。

Facadeパターンとは

Facade(ファサード)パターンは、システム全体の複雑さを隠し、クライアントがシンプルなインターフェースを通じて操作できるようにするための強力なデザイン手法です。これにより、保守性の向上やシステム間の結合度を低減させることが可能になります。 Facadeパターンでは、複数のサブシステムやコンポーネントが持つ複雑な操作を、一つのシンプルなインターフェースにまとめ上げます。具体的には、各処理の呼び出しや連携の方法をFacadeクラスに集約することで、クライアントは複数の内部処理の詳細を意識せずに利用できます。

たとえば、各モジュールで初期化、設定、実行といった処理がバラバラに存在する場合、Facadeクラスがそれらを一元化し、「全体の処理をワンストップで実行する」メソッドを提供します。これにより、変更があった場合はFacade内部の実装のみを修正すればよく、クライアント側の影響を最小限に抑えることが可能になります。

以下のポイントが主なメリットです:

サブシステム毎の複雑な処理を隠蔽し、シンプルなAPIを提供
開発者はFacadeのみを通じて操作するため、クライアントコードがシンプルに保たれる
内部実装の変更が容易となり、メンテナンス性が向上

このように具体的なコード例を通じて、Facadeパターンがどのようにシステムの複雑さを解消し、全体の設計をシンプルかつ柔軟にするのかを解説します。

実践

RustでFacadeパターンを説明していきます。ここではEmployeeDataという構造体と複数のサブシステムとしてEmployeeDataにたいしてデータ検証・保存・フォーマットを行う処理を書いていきます。

EmployeeData

// 従業員データを表す構造体
#[derive(Debug, Clone)]
struct EmployeeData {
    id: u32,
    name: String,
    email: String,
}

サブシステム1(データ検証)

struct EmployeeValidator;

impl EmployeeValidator {
      fn validate(&self, employee: &EmployeeData) -> Result<(), String> {
        if employee.name.is_empty() {
            return Err("Name cannot be empty".to_string());
        }
        if !employee.email.contains("@") {
            return Err("Email format is invalid".to_string());
        }
        Ok(())
    }
}

サブシステム2(データ保存)

use std::collections::HashMap;
use std::sync::{Arc, Mutex};

struct EmployeeRepository {
    // 簡易的にインメモリとしてDBを実装
    storage: Arc<Mutex<HashMap<u32, EmployeeData>>>,
}

impl EmployeeRepository {
    fn new() -> Self {
        EmployeeRepository {
            storage: Arc::new(Mutex::new(HashMap::new())),
        }
    }

    fn save(&self, employee: EmployeeData) {
        let mut db = self.storage.lock().unwrap();
        db.insert(employee.id, employee);
    }

    fn fetch_by_id(&self, id: u32) -> Option<EmployeeData> {
        let db = self.storage.lock().unwrap();
        db.get(&id).cloned()
    }
}

サブシステム3(データフォーマット)

struct EmployeeFormatter;

impl EmployeeFormatter {
    fn format(&self, employee: &EmployeeData) -> String {
        format!(
            "Employee[ID: {}, Name: {}, Email: {}]",
            employee.id, employee.name, employee.email
        )
    }
}

では、まず初めにFacadeパターンを扱わずにmain関数ないでデータの検証から保存整形まで行うパターンを書きます。

fn main() {
    // 各サブシステムのインスタンスを生成
    let validator = EmployeeValidator;
    let repository = EmployeeRepository::new();
    let formatter = EmployeeFormatter;

    let emp = EmployeeData {
        id: 1,
        name: "Alice".to_string(),
        email: "[email protected]".to_string(),
    };

    // クライアント側で各処理を個別に呼び出す必要がある
    // 1. 検証
    match validator.validate(&emp) {
        Ok(()) => {
            // 2. 保存
            repository.save(emp.clone());
            println!("Employee added successfully.");
        }
        Err(err) => {
            println!("Failed to add employee: {}", err);
            return;
        }
    }

    // 3. データ取得と整形
    if let Some(employee) = repository.fetch_by_id(1) {
        let info = formatter.format(&employee);
        println!("Employee info: {}", info);
    } else {
        println!("Employee not found.");
    }
}

クライアントは各サブシステム（検証、保存、整形）を直接管理しなければならず、どの順序で呼び出すか、どのようにエラー処理するかを自前で実装する必要があります。これはクライアント側で各サブシステムの処理を個別に呼び出す必要があり、全体の流れやエラー処理の統一性が失われ、将来的な変更がシステム全体に波及するリスクが高まります。 Facadeパターンを導入することで、これらの問題を1箇所に集約し、クライアントはシンプルなインターフェースのみを扱えばよくなるため、保守性が大幅に向上します。

具体例として以下のようなEmployeeManagerという構造体を用意し実装します。

// Facade: EmployeeManager
struct EmployeeManager {
    validator: EmployeeValidator,
    repository: EmployeeRepository,
    formatter: EmployeeFormatter,
}

impl EmployeeManager {
    fn new() -> Self {
        EmployeeManager {
            validator: EmployeeValidator,
            repository: EmployeeRepository::new(),
            formatter: EmployeeFormatter,
        }
    }

    // 従業員を追加する操作：内部で検証と保存を実行
    fn add_employee(&self, employee: EmployeeData) -> Result<(), String> {
        self.validator.validate(&employee)?;
        self.repository.save(employee);
        Ok(())
    }

    // 従業員情報を取得して整形済みの文字列で返す操作
    fn get_employee_info(&self, id: u32) -> Option<String> {
        self.repository.fetch_by_id(id)
            .map(|employee| self.formatter.format(&employee))
    }
}

EmployeeManagerを用いいてもう一度main関数で同様の処理を書きます。

fn main() {
    let manager = EmployeeManager::new();

    let emp = EmployeeData {
        id: 1,
        name: "Alice".to_string(),
        email: "[email protected]".to_string(),
    };

    // 従業員追加処理
    match manager.add_employee(emp.clone()) {
        Ok(()) => println!("Employee added successfully."),
        Err(err) => println!("Failed to add employee: {}", err),
    }

    // 従業員情報取得
    if let Some(info) = manager.get_employee_info(1) {
        println!("Employee info: {}", info);
    } else {
        println!("Employee not found.");
    }
}

クライアント（main関数）は、EmployeeManagerのadd_employeeやget_employee_infoというシンプルなメソッドを呼び出すだけで、内部の複雑な処理（検証、保存、整形）を実行できました。また、例えば検証ルールを変更したい場合や、データ保存の方式を変更したい場合は、EmployeeManager内部の各サブシステムの実装を変更すればよく、クライアント側のコードはそのまま利用可能です。

各サブシステムの特定の責務が隠蔽されFacadeクラスが吸収するおかげでクライアント側にシンプルなインターフェイスを提供できました。

Facadeパターンにおける注意点

Facadeパターンは、先ほどのように簡単な実装でクライアントへ簡潔なAPIを提供する一方で、依存関係管理に注意が必要になってきます。 Facadeクラスがサービスの境界を定義しますが、Facadeクラスがサービスに依存することによって内部実装で依存させたくないサブシステムにもクライアントを等して間接的に全てのサブシステムに依存することになります。このためFacadeパターンはシンプルさを優先するために依存性の管理と柔軟性を犠牲にしているとも言えます。

まとめ

Facadeパターンは、システム内の複雑な処理や複数のサブシステムを一つの統一されたインターフェースでまとめることで、クライアントに対してシンプルな操作方法を提供します。以下に、そのメリット、デメリット、そして具体的にどのようなケースで利用すべきかを整理します。

メリット

シンプルなAPIの提供:
Facadeクラスを介して複数の処理をまとめることで、クライアントは各サブシステムの詳細を意識せずに必要な機能を利用できます。これにより、クライアントコードがシンプルになり、理解しやすくなります。
内部実装の隠蔽:
各サブシステムの複雑なロジックや依存関係をFacade内部に隠すことで、内部の変更がクライアントに波及しにくくなり、メンテナンス性が向上します。
一元管理による統一性:
様々な処理やエラー処理の流れを一箇所で管理できるため、システム全体の動作の一貫性を保つことができます。

デメリット

依存関係の集中:
Facadeクラスが各サブシステムに依存するため、Facade自体が大きくなり過ぎたり、内部の変更がFacadeの再設計を要求する場合があります。特に、すべてのコンポーネントをパブリックにしてしまうと、システム全体に影響が及ぶリスクが高まります。
柔軟性の低下:
一度Facadeで全体の操作を統一してしまうと、個々のサブシステムに対して細かい制御や最適化を行いにくくなる可能性があります。また、特殊な処理を直接利用したい場合には、Facade経由では対応が難しくなることもあります。
拡張性の制約:
シンプルさを優先するあまり、後から新たな機能や処理を追加する場合に、Facadeクラスに大きな変更を迫られる可能性があります。

使うべきケース

Facadeパターンは、以下のような状況で効果を発揮します。

複雑なサブシステムの抽象化:
複数のモジュールやコンポーネントが連携するシステムにおいて、クライアント側が各コンポーネントの呼び出し順序やエラー処理を個別に管理するのが困難な場合、Facadeを用いることで操作が統一され、開発効率が向上します。
保守性・拡張性の向上:
内部の実装変更（例えば、検証ルールやデータ保存方式の変更）をクライアントに影響させずに行いたい場合、Facadeクラスで一元管理しておくと、変更箇所を限定できるため、システム全体の保守性が高まります。
外部APIの公開:
システム内部の複雑な処理を隠蔽し、外部に対してシンプルで安全なインターフェースを提供する場合にも、Facadeパターンは適しています。
初期実装の簡素化:
プロトタイピングや初期段階でのシステム構築時に、複雑な依存関係を管理する前に、まずはFacadeを用いてシンプルなAPIを実装し、後から内部実装を整理するというアプローチにも向いています。

このように、Facadeパターンはシンプルさと保守性の向上に大いに寄与する一方で、依存関係の集中や柔軟性の低下といったトレードオフが存在します。システムの規模や要件、また将来的な拡張性を見据えた上で、Facadeパターンを適用するかどうかを判断することが重要です。

Sattosh Blog.

SOLID原則とは？

Single Responsibility Principle (SRP):

Open/Closed Principle (OCP):

Liskov Substitution Principle (LSP):

Interface Segregation Principle (ISP):

Dependency Inversion Principle (DIP):

Facadeパターンとは

実践

EmployeeData

サブシステム1(データ検証)

サブシステム2(データ保存)

サブシステム3(データフォーマット)

Facadeパターンにおける注意点

まとめ

メリット

シンプルなAPIの提供:

内部実装の隠蔽:

一元管理による統一性:

デメリット

依存関係の集中:

柔軟性の低下:

拡張性の制約:

使うべきケース

複雑なサブシステムの抽象化:

保守性・拡張性の向上:

外部APIの公開:

初期実装の簡素化: