DocsPricingBlog
Contact Us
Log inSign up for FREE
Back to Tech Articles

Rust Traitsによる柔軟でテスト可能なサービスレイヤーの構築

Oct 17, 2025
# Misc

Grace Collins

Solutions Engineer · Leapcell

This post is also available in English, 한국어, and Deutsch
Cover of "Rust Traitsによる柔軟でテスト可能なサービスレイヤーの構築"

はじめに

現代のソフトウェア開発においては、保守性が高く拡張性のあるアプリケーションを構築することが最重要です。適切に構造化されたアプリケーションは、ビジネスロジックが「サービスレイヤー」内にカプセル化され、関心の分離が明確になることで恩恵を受けます。しかし、適切な設計なしでは、このサービスレイヤーは特定のインプリメンテーションと密結合になり、テストが困難で将来の変更が難しいものになる可能性があります。ここで、抽象化の力、特に依存性注入（DI）とテスト容易性が重要になります。Rustエコシステムでは、Traitsがサービスレイヤー内でこれらの目標を達成するためのエレガントでイディオマティックなソリューションを提供します。この記事では、Rust Traitsを効果的に使用してサービス依存関係を抽象化し、よりモジュール化され、テスト可能で、堅牢なアプリケーションアーキテクチャを実現する方法を掘り下げます。

コアコンセプトの説明

実装の詳細に入る前に、この議論の中心となるいくつかの重要な用語を明確にしましょう：

  • サービスレイヤー: アプリケーションのビジネスロジックをカプセル化するアーキテクチャレイヤーです。プレゼンテーションレイヤー（例：Webハンドラー）が対話できるAPIを提供し、データリポジトリなどの低レベルコンポーネントを含む操作をオーケストレーションします。
  • 依存性注入（DI）: コンポーネントが依存関係を外部ソースから受け取るソフトウェアデザインパターンです。これにより、コンポーネントはそれ自体で作成するのではなく、疎結合が促進され、コンポーネントはより独立し、テストしやすくなります。
  • Trait（Rust）: 共有される動作を定義するためのRustのメカニズムです。Traitは、型がそのTraitを「実装」していると見なされるために実装する必要があるメソッドのセットを定義します。Traitは他の言語のインターフェースに似ていますが、より強力な機能を提供します。
  • テスト容易性: コンポーネントまたはシステムがテストされやすい度合いです。高いテスト容易性は通常、疎結合、明確な責任、およびテストのためにコンポーネントを分離する能力を意味します。

Rust Traitsによるサービスレイヤーの抽象化

中心的なアイデアは、サービスレイヤーの依存関係とサービスレイヤー自体の契約を表すTraitを定義することです。具体的な型を直接インスタンス化するのではなく、サービスレイヤーはTraitオブジェクトまたはこれらのTraitによって制約されたジェネリック型で操作します。これにより、実行時またはテスト中に異なるインプリメンテーションを「注入」することができます。

例：ユーザー管理サービス

簡単なユーザー管理アプリケーションを考えてみましょう。データベースとやり取りするためのUserRepositoryと、ユーザーに関連するビジネスロジックを処理するためのUserServiceが必要になります。

ステップ1：依存関係のためのTraitを定義する

まず、UserRepositoryのTraitを定義します。このTraitは、find_by_idやsaveなど、サービスがユーザーリポジトリに必要とする操作を指定します。

// src/traits.rsまたは類似のファイル
use async_trait::async_trait;
use crate::models::{User, UserId}; // UserモデルとUserId型が存在すると仮定

#[async_trait]
pub trait UserRepository {
    async fn find_by_id(&self, id: &UserId) -> anyhow::Result<Option<User>>;
    async fn save(&self, user: User) -> anyhow::Result<User>;
    // その他のリポジトリメソッド...
}

#[async_trait]属性に注意してください。RustのTraitはTraitオブジェクトで非同期メソッドを直接サポートしていないため、async_traitはTraitで非同期関数を定義および使用できるようにする、広く使用されているクレートです。

ステップ2：具体的な依存関係を実装する

次に、UserRepository Traitの具体的なインプリメンテーションを作成できます。たとえば、PostgresUserRepositoryとテスト用のMockUserRepositoryです。

// src/infra/mod.rsまたは類似のファイル
use sqlx::{PgPool, Postgres}; // 例：データベース操作にsqlxを使用
use crate::models::{User, UserId};
use crate::traits::UserRepository;
use anyhow::anyhow;

pub struct PostgresUserRepository {
    pool: PgPool,
}

impl PostgresUserRepository {
    pub fn new(pool: PgPool) -> Self {
        PostgresUserRepository { pool }
    }
}

#[async_trait]
impl UserRepository for PostgresUserRepository {
    async fn find_by_id(&self, id: &UserId) -> anyhow::Result<Option<User>> {
        // プレースホルダー：実際のデータベースクエリがここに入ります
        println!("PostgreSQLからユーザー {} を取得中", id.0);
        Ok(Some(User { id: id.clone(), name: "John Doe".to_string(), email: format!("{}@example.com", id.0) }))
        // sqlx::query_as!(User, "SELECT id, name, email FROM users WHERE id = $1", id.0)
        //     .fetch_optional(&self.pool)
        //     .await
        //     .map_err(|e| anyhow!("ユーザー取得に失敗しました: {}", e))
    }

    async fn save(&self, user: User) -> anyhow::Result<User> {
        // プレースホルダー：実際のデータベース挿入/更新
        println!("PostgreSQLにユーザー {} を保存中", user.id.0);
        Ok(user)
        // sqlx::query_as!(User, "INSERT INTO users (id, name, email) VALUES ($1, $2, $3) ON CONFLICT(id) DO UPDATE SET name=$2, email=$3 RETURNING id, name, email",
        //     user.id.0, user.name, user.email)
        //     .fetch_one(&self.pool)
        //     .await
        //     .map_err(|e| anyhow!("ユーザー保存に失敗しました: {}", e))
    }
}

// src/tests/mocks.rsまたは類似のファイル
use std::collections::HashMap;
use parking_lot::RwLock; // モックでのスレッドセーフmutableアクセスのため
use crate::models::{User, UserId};
use crate::traits::UserRepository;

pub struct MockUserRepository {
    users: RwLock<HashMap<UserId, User>>,
}

impl MockUserRepository {
    pub fn new() -> Self {
        MockUserRepository {
            users: RwLock::new(HashMap::new()),
        }
    }

    pub fn insert_user(&self, user: User) {
        self.users.write().insert(user.id.clone(), user);
    }
}

#[async_trait]
impl UserRepository for MockUserRepository {
    async fn find_by_id(&self, id: &UserId) -> anyhow::Result<Option<User>> {
        println!("Mockからユーザー {} を取得中", id.0);
        Ok(self.users.read().get(id).cloned())
    }

    async fn save(&self, user: User) -> anyhow::Result<User> {
        println!("Mockにユーザー {} を保存中", user.id.0);
        self.users.write().insert(user.id.clone(), user.clone());
        Ok(user)
    }
}

注意：簡潔さのため、UserとUserIdのモデル定義は省略されていますが、存在すると仮定します。

ステップ3：サービスTraitを定義する（オプションですが推奨）

より複雑なサービス、またはレイヤー全体の異なるインプリメンテーションを許可したい場合は、UserServiceのTraitを定義することもできます。これは、同じサービスの異なる戦略的バージョンがある場合に特に役立ちます。

// src/traits.rsまたは類似のファイル
#[async_trait]
pub trait UserService {
    async fn get_user_by_id(&self, id: &UserId) -> anyhow::Result<Option<User>>;
    async fn create_user(&self, name: String, email: String) -> anyhow::Result<User>;
    // その他のサービスメソッド...
}

ステップ4：Traitオブジェクトまたはジェネリクスを使用してサービスを実装する

次に、UserServiceを実装します。UserRepositoryに依存するのではなく、UserRepositoryを実装する任意の型に依存します。

Option A：Traitオブジェクト (Box<dyn Trait>)

これは、同じTraitを実装するさまざまな具体的なインプリメンテーションを格納する必要がある場合に、最も簡単なアプローチであることがよくあります。

// src/services/mod.rsまたは類似のファイル
use std::sync::Arc; // 共有所有権のためにArcを使用
use uuid::Uuid;
use crate::models::{User, UserId};
use crate::traits::{UserRepository, UserService};

pub struct UserServiceImpl {
    user_repo: Arc<dyn UserRepository>, // 依存関係はTraitオブジェクトとして注入される
}

impl UserServiceImpl {
    // UserRepositoryを実装する型を受け取り、Arc<dyn UserRepository>に変換するコンストラクタ
    pub fn new(user_repo: Arc<dyn UserRepository>) -> Self {
        UserServiceImpl { user_repo }
    }
}

#[async_trait]
impl UserService for UserServiceImpl {
    async fn get_user_by_id(&self, id: &UserId) -> anyhow::Result<Option<User>> {
        self.user_repo.find_by_id(id).await
    }

    async fn create_user(&self, name: String, email: String) -> anyhow::Result<User> {
        let new_user = User {
            id: UserId(Uuid::new_v4().to_string()),
            name,
            email,
        };
        self.user_repo.save(new_user).await
    }
}

Option B：ジェネリクス

ジェネリクスはコンパイル時の型チェックを提供し、モジュロ化によるモノモルフィゼーションにより、より良いパフォーマンスを提供する場合があります。依存関係の具体的な型がコンパイル時にわかっていて、実行時に動的にインプリメンテーションを切り替える必要がない場合に適しています。

// src/services/mod.rsまたは類似のファイル
// ...インポート...

pub struct UserServiceImplGeneric<R: UserRepository> { // RはUserRepository Traitによって制約されたジェネリック型
    user_repo: R,
}

impl<R: UserRepository> UserServiceImplGeneric<R> {
    pub fn new(user_repo: R) -> Self {
        UserServiceImplGeneric { user_repo }
    }
}

#[async_trait]
impl<R: UserRepository + Send + Sync> UserService for UserServiceImplGeneric<R> { // RもAsync TraitのためにSend + Syncである必要があります
    async fn get_user_by_id(&self, id: &UserId) -> anyhow::Result<Option<User>> {
        self.user_repo.find_by_id(id).await
    }

    async fn create_user(&self, name: String, email: String) -> anyhow::Result<User> {
        let new_user = User {
            id: UserId(Uuid::new_v4().to_string()),
            name,
            email,
        };
        self.user_repo.save(new_user).await
    }
}

サービスレイヤーの場合、Box<dyn Trait>（または共有所有権のためのArc<dyn Trait>）は、コレクション内でさまざまな具体的な型を混合したり、動的に切り替えたりできるため、依存性注入の柔軟性から好まれることが多いです。ジェネリクスは、より基本的なビルディングブロックや、パフォーマンスが絶対に重要であり、モノモルフィゼーションが許容される状況に優れています。

ステップ5：配線（依存性注入）

メインアプリケーションのエントリポイント（例：main.rsまたはDIコンテナ）で、具体的な依存関係をインスタンス化し、サービスに注入できます。

// src/main.rsまたはWebフレームワークのアプリケーションセットアップ
use std::sync::Arc;
use crate::infra::PostgresUserRepository;
use crate::services::UserServiceImpl; // Traitオブジェクトバージョンを使用すると仮定
use crate::traits::{UserRepository, UserService};
use crate::models::UserId;

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    // 1. 具体的な依存関係を初期化する
    // let pool = PgPool::connect("postgresql://user:password@localhost/db").await?;
    // let concrete_repo = PostgresUserRepository::new(pool);
    // この例のために、ダミーリポジトリを作成しましょう
    let concrete_repo = PostgresUserRepository::new(
        sqlx::PgPool::connect("postgres://user:password@localhost/db")
            .await
            .unwrap_or_else(|_| panic!("例でDBに接続できませんでした"))); // ダミープール


    // 2. 具体的なインプリメンテーションからArc<dyn Trait>を作成する
    let user_repo: Arc<dyn UserRepository> = Arc::new(concrete_repo);

    // 3. 依存関係をサービスに注入する
    let user_service = UserServiceImpl::new(user_repo.clone());

    // 4. サービスを使用する
    println!("--- アプリケーションロジック ---");
    let user_id = UserId("123".to_string());
    user_service.create_user("Alice".to_string(), "alice@example.com".to_string()).await?;
    if let Some(user) = user_service.get_user_by_id(&user_id).await? {
        println!("ユーザーが見つかりました: {} ({})", user.name, user.email);
    } else {
        println!("ユーザー {} が見つかりませんでした。", user_id.0);
    }

    Ok(())
}

ステップ6：テスト容易性の向上

このセットアップは、テスト容易性を大幅に向上させます。MockUserRepositoryを注入することで、UserServiceを単独でテストできるようになります。

// src/services/mod.rsまたはsrc/services/tests.rs
#[cfg(test)]
mod tests {
    use super::*;
    use crate::tests::mocks::MockUserRepository; // 私たちのモックインプリメンテーション
    use crate::models::{User, UserId};

    #[tokio::test]
    async fn test_create_user() -> anyhow::Result<()> {
        let mock_repo = Arc::new(MockUserRepository::new());
        let user_service = UserServiceImpl::new(mock_repo.clone());

        let new_user = user_service.create_user("Bob".to_string(), "bob@example.com".to_string()).await?;

        // モックリポジトリを確認して、ユーザーが「保存」されたことを検証する
        let fetched_user = mock_repo.find_by_id(&new_user.id).await?;
        assert!(fetched_user.is_some());
        assert_eq!(fetched_user.unwrap().name, "Bob");

        Ok(())
    }

    #[tokio::test]
    async fn test_get_user_by_id_found() -> anyhow::Result<()> {
        let mock_repo = Arc::new(MockUserRepository::new());
        let user_id = UserId("456".to_string());
        mock_repo.insert_user(User {
            id: user_id.clone(),
            name: "Charlie".to_string(),
            email: "charlie@example.com".to_string(),
        });

        let user_service = UserServiceImpl::new(mock_repo);

        let user = user_service.get_user_by_id(&user_id).await?;
        assert!(user.is_some());
        assert_eq!(user.unwrap().name, "Charlie");
        Ok(())
    }

    #[tokio::test]
    async fn test_get_user_by_id_not_found() -> anyhow::Result<()> {
        let mock_repo = Arc::new(MockUserRepository::new());
        let user_service = UserServiceImpl::new(mock_repo);

        let user_id = UserId("789".to_string());
        let user = user_service.get_user_by_id(&user_id).await?;
        assert!(user.is_none());
        Ok(())
    }
}

結論

Rust Traitsを通じてサービス依存関係とサービスレイヤー自体の契約を綿密に定義することで、柔軟で堅牢なアプリケーションを構築するための強力なパターンを解き放ちます。このアプローチは、明確な依存性注入を可能にし、テストや実行時の異なる環境のために具体的なインプリメンテーションを切り替えることができます。これにより、サービスの中核ロジックを変更することなく、テスト容易性の高いコードベース、コンポーネント間の結合度の低下、および保守性の高いアプリケーションアーキテクチャが実現します。サービスレイヤーの抽象化にRust Traitsを採用することは、時の試練と変化に耐える、適切に設計されたRustアプリケーションを作成するための基盤となります。

Share this article

HackerNews

More Posts from Leapcell

Popular Posts