アーキテクチャ

Webアプリケーション開発においてレイヤードアーキテクチャは広く採用されていますが、Rustで同じ設計を適用しようとすると、所有権やライフタイムといった言語固有の制約に直面します。「Rustとレイヤードアーキテクチャは相性がよいのか」という疑問は、Rustでの本格的なアプリケーション開発を検討する多くのエンジニアが抱える課題です。 結論として、Rustとレイヤードアーキテクチャの相性は良好です。ただし、JavaやGoと同じ感覚で実装するとコンパイルエラーに阻まれます。Rust固有の仕組みを理解した上で設計すれば、型安全性とレイヤー分離の両方を高いレベルで実現できます。 レイヤードアーキテクチャの基本構造 レイヤードアーキテクチャは、アプリケーションを責務ごとに水平な層（レイヤー）に分割する設計手法です。一般的な4層構成は以下のとおりです。 層 責務 Rustでの実装単位 プレゼンテーション層 HTTPリクエスト/レスポンス処理 axumのHandler・Router アプリケーション層 ユースケースの実行、トランザクション管理 サービス構造体 ドメイン層 ビジネスルール、エンティティ、値オブジェクト 構造体 + impl インフラストラクチャ層 DB接続、外部API呼び出し トレイト実装体 各層は上位から下位への一方向の依存関係を持ち、ドメイン層は他のどの層にも依存しません。この原則により、ビジネスロジックがフレームワークやDBの実装詳細から分離されます。 Rustの言語特性がレイヤード設計と噛み合うポイント 所有権システムによるデータフローの明示化 Rustの所有権（ownership）は、レイヤー間のデータ受け渡しを明示的にします。JavaやGoではオブジェクト参照が暗黙的にコピーされますが、Rustでは値の移動（move）が基本です。 // アプリケーション層からドメイン層への値の移動 fn create_user(input: CreateUserInput) -> Result<User, DomainError> { // inputの所有権はこの関数に移動している let name = UserName::new(input.name)?; // input.nameの所有権が移動 let email = Email::new(input.email)?; // input.emailの所有権が移動 Ok(User::new(name, email)) } レイヤー間でデータがどの方向に流れ、どこで消費されるかがコンパイル時に保証されます。これは設計上のミス（意図しないデータ共有や変更）を防ぐ効果があります。 トレイトによる依存性逆転（DIP） レイヤードアーキテクチャでは、上位層が下位層の具体的な実装に依存しないことが重要です。Rustではトレイト（trait）を使ってこの依存性逆転の原則（Dependency Inversion Principle）を自然に実現できます。 // ドメイン層でリポジトリのインターフェースを定義 #[async_trait] pub trait UserRepository: Send + Sync { async fn find_by_id(&self, id: &UserId) -> Result<Option<User>, RepositoryError>; async fn save(&self, user: &User) -> Result<(), RepositoryError>; } // アプリケーション層はトレイトに依存（具体実装には依存しない） pub struct UserService<R: UserRepository> { repository: R, } impl<R: UserRepository> UserService<R> { pub fn new(repository: R) -> Self { Self { repository } } pub async fn get_user(&self, id: &UserId) -> Result<Option<User>, AppError> { self.repository .find_by_id(id) .await .map_err(AppError::from) } } ジェネリクスとトレイト境界を組み合わせることで、コンパイル時に型チェックが行われ、実行時のオーバーヘッドなしにDIPを実現できます。JavaのインターフェースやGoのインターフェースと異なり、Rustのトレイトはゼロコスト抽象化として機能します。 ...