既存の決済基盤に 決済手段追加で学んだこと

Transcript

1. 既存の決済基盤に 決済手段追加で学んだこと
2. ⾃⼰紹介 名前 佐藤 律史 趣味 ドッジボール ゲーム（フォートナイト） お笑い（千鳥） 好きなツール GPT Live
3. 背景 予約システムを刷新している（ Rails → NestJS） その一環で、決済基盤も新しく作り直している その決済基盤に、新しい決済手段を追加している
4. 決済基盤の全体像（ざっくり） 予約 決済代行会社 目標金額（利用金額・キャンセル料など） 今の決済状態（いくら与信済みか） 計画する 目標金額と決済状態を比較して、必要な操作を判断する 必要な操作（例：仮売上を取る/ 金額を変える / 返金する） 実行する → 決済代行会社の API を呼んで、実際に仮売上や返金を行う
5. 決済の中⼼にある Policy から設計しようとした Policy とは目標金額・決済状態から、必要な決済操作を判断するドメインサービス 決済状態 ・ 目標金額 type Context = { detailHistories: PaymentDetailHistory[] chargeState: ChargeState providerConstraintState: PaymentProviderConstraintState } Policy 必要な決済操作の計画
6. ドメインモデルは、決済業務の何を表しているのか 決済ドメインで表現している概念 担うモデル・サービス 目標となる決済状態 PaymentDetailHistory 決済状態 ChargeState 決済操作 PaymentOperation 必要な操作を決めるルール Policy 決済手段ごとの状態 ProviderConstraintState
7. 現実の決済フローに合わせて、ドメインモデルの役割が⾒えてきた 目標となる決済状態 決済状態 PaymentDetailHistory ChargeState 必要な操作を決めるルール Policy 決済開始 仮売上 売上確定 決済操作 仮売上取消 決済手段ごとの状態 返金 PaymentOperation ProviderConstraintState
8. 既存モデルを理解したうえで、楽天ペイの設計に⼊った。 そこで、ひとつ悩んだことがあった。
9. 楽天ペイには、仮売上の前に認証の段階がある 認証・同意の完了後に、初めて仮売上になる Charge を作成 ユーザー認証待ち 認証・同意が完了 仮売上 売上確定 または取消
10. 既存モデルに、そのまま当てはめられなかった 既存モデルが扱っていた状態 仮売上 売上確定 仮売上取消 返金 Charge 作成済み・仮売上前 ・Charge は存在する ・まだ仮売上ではない ？ class RakutenPayChargeState { readonly #providerStatus: Status readonly #isActive: boolean readonly #captureExpireAt: Date | null readonly #cancelExpireAt: Date | null }
11. これが正解かは、まだ分からない RakutenPayChargeState 楽天ペイ固有の概念 ？ 複数の決済手段に共通する 「決済開始後・仮売上前」の概念
12. 今回の学びと気づき 1 ドメインモデルが対象業務のどこを表すかという視点を持つ 2 DDDを取り入れた設計では、 業務ルールを理解するだけでは設計に落とし込みづらかった 3 業務の変化に合わせて、ドメインモデルも見直す必要がある
13. Thank you