Repository：PostgreSQL RPCとの境界

なぜJPAやJDBCを使わないのか

既存Minibankでは、振込の正式な入口がPostgreSQLのrequest_transfer()とconfirm_transfer_otp()です。Javaからテーブルを直接更新すると、RLS、関数権限、ロック順序、台帳記帳、監査を迂回する危険があります。

PaymentRpcGatewayは既存RPCへ必要な引数を渡し、返却行をドメインモデルへ変換する役割だけを持ちます。

RPC呼び出しの流れ

1. 01Gatewayがp_*形式の引数Mapを作る
2. 02SupabaseRpcClientがPOST /rpc/{fn}を呼ぶ
3. 03publishable keyと呼出者のAuthorizationを送る
4. 04PostgRESTがtokenを解釈しPostgreSQL関数を実行
5. 05JSON配列をMapへ読み取る
6. 06GatewayがPendingPaymentまたはPaymentOtpConfirmationへ変換

Bearer tokenを引き継いで認可文脈を保つ

Javaサービス自身の強い権限でRPCを呼ぶのではなく、利用者のBearer tokenを転送します。そのためauth.uid()と既存RLS・RPCの認可判断を引き続き使えます。

これはtokenを信頼するという意味ではありません。有効性はPostgREST側で検証され、Javaは形式と伝搬を担当します。

restClient.post()
    .uri("/rpc/{fn}", functionName)
    .header(HttpHeaders.AUTHORIZATION, bearerToken)
    .body(params)
    .retrieve();

DBエラーを公開契約へ翻訳する

PostgreSQL関数はTR003やTR010などのSQLSTATEで失敗理由を表します。RpcErrorMapperがそれをApiErrorCodeと安全な日本語メッセージへ変換します。

未知のSQLSTATEやJSONとして読めない応答はINTERNAL_ERRORへ閉じます。内部メッセージをそのまま返さないことが、情報漏えいと不安定なAPI契約を防ぎます。