1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
//! # Use Cases(ユースケース)
//!
//! ## Use Caseとは
//!
//! Use Caseは、**1つのユーザーゴールを達成するためのビジネスフロー**を表現します。
//! エンティティやドメインサービスを組み合わせ(オーケストレート)、アプリケーション固有の処理を実現します。
//!
//! ## Use Caseの責務
//!
//! ### ✅ Use Caseが行うこと
//! - ポート(トレイト)を経由した外部システムとの通信
//! - ドメインエンティティ・サービスの呼び出しと調整
//! - トランザクション境界の定義
//! - アプリケーション固有のビジネスフローの実装
//!
//! ### ❌ Use Caseが行わないこと
//! - ドメインロジック(ビジネスルール)の実装
//! → Domain層のエンティティ・値オブジェクト・ドメインサービスが担当
//! - 技術的詳細の実装
//! → Infrastructure層のアダプターが担当
//!
//! ## 設計原則
//!
//! ### 1. Single Responsibility Principle (SRP)
//! 各Use Caseは**1つの変更理由**のみを持つ。
//! - `WatchCalendarChangesUseCase`: カレンダー監視のビジネスフローが変わる
//! - `CreateUsageUseCase`: 使用予定作成のビジネスフローが変わる
//!
//! ### 2. Dependency Inversion Principle (DIP)
//! Use Caseは抽象(ポート)に依存し、具象には依存しない。
//! ```rust,ignore
//! pub struct SomeUseCase<R, N>
//! where
//! R: ResourceUsageRepository, // trait(抽象)に依存
//! N: Notifier, // trait(抽象)に依存
//! ```
//!
//! ### 3. Interface Segregation Principle (ISP)
//! Use Caseは必要最小限のポートにのみ依存する。
//!
//! ### 4. Thin Application Layer
//! Application層は薄く保ち、ドメインロジックをDomain層に配置する。
/// リソース使用予定を作成するユースケース
/// リソース使用予定を削除するユースケース
/// IDでリソース使用予定を取得するユースケース
/// ユーザーにリソースアクセス権を付与するユースケース
/// 全ての未来のリソース使用予定を取得するユースケース
/// ユーザーのリソース使用予定一覧を取得するユースケース
/// 未来のリソース使用変更を監視して通知するユースケース
/// リソース使用予定を更新するユースケース
pub use CreateResourceUsageUseCase;
pub use DeleteResourceUsageUseCase;
pub use GetResourceUsageByIdUseCase;
pub use GrantUserResourceAccessUseCase;
pub use ListAllFutureResourceUsagesUseCase;
pub use ListUserResourceUsagesUseCase;
pub use NotifyFutureResourceUsageChangesUseCase;
pub use UpdateResourceUsageUseCase;