前置き
リトライ系の処理には、ビジネスリトライ系の処理と、技術リトライ系の処理があります。
それぞれがどこに配置されていると望ましいのか？ 軽く整理してみます。
まず、クリーンアーキテクチャの同心円状で言うと、
ビジネスリトライ系の処理は、赤いUse Cases層に配置されるべき責務
です。
なぜUseCases層なのか？
クリーンアーキテクチャの同心円は、「変更の理由」と「依存関係」 によって分離されています。
Entities (内側)
企業全体の普遍的なビジネスルール。（例: 「注文」のステータス定義）
UseCases (中間)
アプリケーション固有のビジネスルール。（例: 「注文を処理する」というフロー）
Adapters / Infrastructure (外側)
フレームワーク、DB、外部APIなど、「どうやって」 を実現するかの技術的詳細。
「ビジネスリトライ」は、「どうやって（How）」ではなく「何を（What）」 を定義するロジックです。
技術的リトライ（Infrastructure層）
例
ネットワークエラー（503）が発生したため、即座に3回まで再試行する。
責務
これはインフラ（例: サービスメッシュやHTTPクライアントライブラリ）の責務です。
UseCasesはこれを知りません。
ビジネスリトライ（UseCases層）
例
決済が「残高不足」（ビジネスルール）で失敗したため、24時間後にもう一度試行する。
責務
この「24時間後に再試行する」というルールは、ネットワークの問題ではなく、アプリケーション固有のビジネスフロー（方針） です。
したがって、このリトライロジックをオーケストレーションする（例: Orderエンティティの状態をRetryPendingにし、スケジューラに登録する）のは、PlaceOrderUseCaseのようなUseCases層の明確な責務となります。