Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
実践オブジェクト指向設計事前課題
Search
Recruit
PRO
August 10, 2023
Technology
1
2.9k
実践オブジェクト指向設計事前課題
2023年度リクルート エンジニアコース新人研修の講義資料です
Recruit
PRO
August 10, 2023
Tweet
Share
More Decks by Recruit
See All by Recruit
あなたの知らない Linuxカーネル脆弱性の世界
recruitengineers
PRO
3
190
dbtとBigQuery MLで実現する リクルートの営業支援基盤のモデル開発と保守運用
recruitengineers
PRO
3
180
『ホットペッパービューティー』のiOSアプリをUIKitからSwiftUIへ段階的に移行するためにやったこと
recruitengineers
PRO
4
1.7k
経営の意思決定を加速する 「事業KPIダッシュボード」構築の全貌
recruitengineers
PRO
4
310
Browser
recruitengineers
PRO
12
3.7k
JavaScript 研修
recruitengineers
PRO
8
2.1k
TypeScript入門
recruitengineers
PRO
37
15k
モダンフロントエンド 開発研修
recruitengineers
PRO
13
7.9k
Webアクセシビリティ入門
recruitengineers
PRO
4
2.2k
Other Decks in Technology
See All in Technology
なぜ新機能リリース翌日にモニタリング可能なのか? 〜リードタイム短縮とリソース問題を「自走」で改善した話〜 / data_summit_findy_Session_2
sansan_randd
1
140
從裝潢設計圖到 Home Assistant:打造智慧家庭的實戰與踩坑筆記
kewang
0
140
今日から使える AWS Step Functions 小技集 / AWS Step Functions Tips
kinunori
5
530
ピープルウエア x スタートアップ
operando
3
3.7k
Amazon Q Developer CLIをClaude Codeから使うためのベストプラクティスを考えてみた
dar_kuma_san
0
360
kotlin-lsp の開発開始に触発されて、Emacs で Kotlin 開発に挑戦した記録 / kotlin‑lsp as a Catalyst: My Journey to Kotlin Development in Emacs
nabeo
2
380
サブドメインテイクオーバー事例紹介と対策について
mikit
16
7.8k
[JDDStudy #10] 社内Agent勉強会の取り組み紹介
yp_genzitsu
1
100
AWS 環境で GitLab Self-managed を試してみた/aws-gitlab-self-managed
emiki
0
300
InsightX 会社説明資料/ Company deck
insightx
0
210
設計に疎いエンジニアでも始めやすいアーキテクチャドキュメント
phaya72
30
20k
コミュニティと共に変化する 私とFusicの8年間
ayasamind
0
340
Featured
See All Featured
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
Rails Girls Zürich Keynote
gr2m
95
14k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
1.7k
Build The Right Thing And Hit Your Dates
maggiecrowley
38
2.9k
The Cult of Friendly URLs
andyhume
79
6.7k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.3k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.5k
Thoughts on Productivity
jonyablonski
73
4.9k
A designer walks into a library…
pauljervisheath
209
24k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Embracing the Ebb and Flow
colly
88
4.9k
Transcript
1 ページ ⾦融機関(⼝座) Fict PAYサーバ 加盟店 決済代⾏業者 システム 今回の開発スコープ Fict
PAYアプリ (iOS/Android) MPM決済: 店舗側のQRコードをスマホアプリでスキャンして実⾏する決済 ※アプリのQRコードを店舗側で読み取るCPM決済は今回はスコープ外 1. MPM決済機能 ・エラーハンドリング等の処理も含めて考慮してみてください ・資料で指定している以外のFict PAYサーバで扱うデータや処理は各⾃で考えてみてください ・決済の取り消しやキャンセルは今回は実装不要です 実装する機能 架空のQR決済サービス『Fict PAY』のサーバサイドを設計・実装してください 実践オブジェクト指向設計︓事前課題 MPM決済の流れ 補⾜ ・MPM決済(店舗のQRコードをアプリで読み込んで⾏う決済)機能 ・アプリ残⾼のチャージ機能 ・ユーザ間の送⾦機能 Fict PAYサーバ 加盟店 決済代⾏業者 システム Fict PAYアプリ (iOS/Android) ③決済リクエスト ①店頭でQRコードの読み取り ②⾦額を指定 ⑤決済代⾏ ⑥処理結果返却 ⑨処理結果返却 ④決済代⾏処理 リクエスト ⑧決済の記録 ⑦Fict PAY残⾼から 差し引き処理 ※Push通知はスコープ外 ※加盟店と店舗は別 例) 加盟店:セブンイレブン 店舗:リクルートサウスタワー店
2 ページ Fict PAYアプリ ⇒ Fict PAYサーバ ・結果コード(resultCode)や結果メッセージは任意で定義してください ・⽇時データのフォーマットは任意で決めてください ・決済⽅式は2種類(MPM:1
CPM:2 ※CPMは今回は対象外) securityDefinitions: # セキュリティ実装は任意 access_token: type: apiKey name: Authorization in: header description: Access token in the format 'Bearer {access_token}' paths: # URL PATH /v1/payments/mpm: # path post: # POST description: Execute MPM Payment requestBody: # リクエストボディ description: MPM Payment Request Body content: application/json: schema: # POSTするオブジェクト schema: type: object properties: customerId: { type: string } # カスタマID terminalId: { type: string } # 端末を識別するためのID merchantId: { type: string } # 加盟店ID storeId: { type: string } # 店舗ID amount: { type: number } # 決済⾦額 currency: { type: string } # 通貨の種別"JPY" pgIdentifier: { type: string } # 決済代⾏業者の識別⼦ paymentDatetime: { type: string } # 決済年⽉⽇ paymentMethod: { type: number } # 決済⽅式(MPMやCPM) security: # セキュリティは任意 - access_token: [] Fict PAYサーバ ⇒ 決済代⾏業者システム 【補⾜】 ・決済事業者:Fict PAY運営元(コード:123456789) ・⽇時データのフォーマットや決済事業者側からの結果メッセージは任意で決めてください ・架空の決済代⾏会社を想定しているため、決済代⾏会社側のシステムのURLホスト名やIPアドレスは任意で決めてください ・決済代⾏事業者側の結果コード(resultCode)は下記 PG1001:決済完了 PG3001:決済失敗 securityDefinitions: # セキュリティの実装は任意 access_token: type: apiKey name: Authorization in: header description: Access token in the format 'Bearer {access_token}' paths: # URL PATH(ホスト名例: "any.gateway.com"等) https://{任意のホストorIP}/v2/pg/payments: # path post: # POST description: Payment Gateway Processing parameters: [] requestBody: # リクエストボディ content: application/json: schema: # POSTするオブジェクト schema: type: object properties: terminalId: { type: string } # 端末を識別するためのID paymentProvCode: { type: string } # 決済事業者コード merchantId: { type: string } # 加盟店ID storeId: { type: string } # 店舗ID amount: { type: number } # 決済⾦額 currency: { type: string } # 通貨の種別"JPY" paymentDate: { type: string } # 決済年⽉⽇ security: # セキュリティの実装は任意 - access_token: [] MPM決済リクエストIF 決済代⾏リクエストIF responses: '200': description: Created content: application/json: schema: type: object properties: resultInfo: resultCode: { type: string } # 任意で決めてください message: { type: string } # "決済が完了しました"等 data: status: { type: string } # "Created" createdAt: { type: string } # 作成⽇時(決済完了⽇時) '400'/'401'/'500': description: BadRequest/Unauthorized/InternalServerError content: application/json: schema: type: object properties: resultInfo: resultCode: { type: string } message: { type: string } responses: '200': description: Created content: application/json: schema: type: object properties: resultInfo: resultCode: { type: string } # 決済代⾏側で決められた結果コード message: { type: string } # 決済代⾏側からのメッセージ data: pgPaymentId: { type: string } # 決済代⾏管理ID acceptedAt: { type: string } # ⽇時(決済代⾏事業者側) '400'/'401'/'500': description: BadRequest/Unauthorized/InternalServerError content: application/json: schema: type: object properties: resultInfo: resultCode: { type: string } message: { type: string } ※Fict PAYアプリが店舗のQRコードから⽂字列を読み取り、パースしてサーバへ送信する想定 ※あくまで架空で、決済代⾏のSDKやライブラリ等は無いため、通信処理は既存のライブラリを使⽤する等で対応してください
3 ページ 残⾼チャージ: 指定した⾦融機関の⼝座から、Fict PAY残⾼(Fict PAYサーバで管理する残⾼)へチャージする機能 2. 残⾼チャージ ・チャージ失敗等時のエラーハンドリング処理等も含めて考慮してみてください ・⾦融機関の⼝座からのチャージには⾦融機関が提供するネット⼝座振替サービスを⽤います
※⾦融機関も架空のものを想定しているため、⾦融機関側のURLホスト名やシステムのIPは任意で決めてください Fict PAYアプリ ⇒ Fict PAYサーバ 送⾦に必要な項⽬を含めて、各⾃で考えてみてください 補⾜ 残⾼チャージリクエストIF Fict PAYサーバ ⇒ ⾦融機関システム(ネット⼝座振替サービス) 【補⾜】 ・委託者:決済事業者(Fict PAY運営元:123456789) ・収納機関:⾦融機関と委託先の間で⼝座振替を代⾏する業者(456563211) ・⽇時データのフォーマットや⾦融機関側からの結果メッセージは任意で決めてください ・預⾦の種別は下記 普通預⾦:1 当座預⾦:2 ・⾦融機関側の結果コード(resultCode)は下記 DB1001:チャージ完了 DB3001:チャージ失敗 ⼝座振替IF securityDefinitions: # セキュリティの実装は任意 access_token: type: apiKey name: Authorization in: header description: Access token in the format 'Bearer {access_token}' paths: # URL PATH(ホスト名例: "fin.inst.co.jp"等) https://{任意のホスト名 or IP}/v2/account/debit: # path post: # POST requestBody: # リクエストボディ content: application/json: schema: # POSTするオブジェクト schema: type: object properties: debitDatetime { type: string } # チャージ⽇時 debitAmount: { type: number } # チャージ⾦額 bankCode: { type: string } # ⾦融機関コード branchCode: { type: string } # ⽀店コード bankAccountType: { type: number } # 預⾦種別 accountNumber: { type: string } # ⼝座番号 accountNameKana: { type: string } # ⼝座⽒名(カナ) collectionOrgCode: { type: string } # 収納機関コード(456563211) consignorCode: { type: string } # 委託者コード(123456789) 残⾼チャージの流れ Fict PAYサーバ ⾦融機関(⼝座) Fict PAYアプリ (iOS/Android) ③チャージ リクエスト ①⾦融機関を選択 ②⾦額を指定 ⑤処理結果返却 ⑧チャージ結 果返却 ④⼝座振替リク エスト ⑥Fict PAY残⾼へ のチャージ ⑦チャージの記録 responses: '200': description: Created content: application/json: schema: type: object properties: resultInfo: resultCode: { type: string } # ⾦融機関側で決められたコード message: { type: string } # 任意で決めてください data: debitMgmtCode: { type: string } # 振替管理コード acceptedAt: { type: string } # ⽇時(⾦融機関側) '400'/'401'/'500': description: BadRequest/Unauthorized/InternalServerError content: application/json: schema: type: object properties: resultInfo: resultCode: { type: string } message: { type: string } ※あくまで架空で、⾦融機関のSDKやライブラリ等は無いため、通信処理は既存のライブラリを使⽤する等で対応してください ※Push通知はスコープ外
4 ページ 送⾦: ユーザ同⼠でID検索して、Fict PAY残⾼で送⾦し合う機能 ・残⾼不⾜や送⾦失敗等のエラーハンドリング処理も含めて考慮してみてください ・送⾦前に検索するユーザIDは既に登録済みの想定で構いません ※本⽂に記載の仕様は現実のQR決済サービスの仕様をデフォルメ・改変しております 1. Fict
Pay各機能のURLパス(⽂字列等)は特に指定はありませんので任意で決めてください 2. リクエスト、レスポンスともにフォーマットはJSONを使⽤してください(画⾯は不要です) 3. Fict PAYサーバのSSL (https) の対応は今回は不要です 4. 決済代⾏業者や⾦融機関システムとのサーバ間通信の際の認証等は今回は任意とします (各種認証や接続ハンドル等は使⽤せずにシンプルにHTTPリクエストする形式でもOK) 5. 各APIのリクエスト・レスポンスの具体的な値を各⾃で想定しながら作ってみてください 6. 「〇〇番号」や「△△コード」等の項⽬の値は指定が無い限り、任意で決めてください 7. その他、以下の機能は今回はスコープ外のため、任意実装で構いません ・ユーザ登録(既に登録済みの想定) ・アプリのユーザ認証(Fict PAYアプリとFict PAYサーバ間の認証は必須ではありません) ・本⼈確認やeKYCは既に実施済みの想定 ・⾦融機関登録(既に登録済みの想定) ・⼝座振替登録(⼝座振替サービスを使⽤する前に必要だが、今回は⾦融機関に依頼済みの想定) ・アプリへのPush通知(スコープ外) ・Fict PAYサーバの管理者⽤機能(スコープ外) 送⾦の流れ 補⾜ 3. 送⾦ 4. その他補⾜ Fict PAYアプリ ⇒ Fict PAYサーバ 送⾦に必要な項⽬も含めて、各⾃で考えてみてください 送⾦リクエストIF Fict PAYアプリ ⇒ Fict PAYサーバ 履歴確認に必要な項⽬も含めて、各⾃で考えてみてください 送⾦・着⾦履歴確認IF 送⾦側ユーザ 送⾦先ユーザ Fict PAYサーバ Fict PAYアプリ (iOS/Android) ③送⾦リクエスト ①ID検索で送⾦先を指定 ②⾦額を指定 ④送⾦側と送⾦先の Fict PAY残⾼の増減処理 ⑧送⾦・着⾦履歴 返却(任意) ⑥送⾦処理結果返却 ⑦送⾦・着⾦履歴確認(任意) リクエスト Fict PAYアプリ (iOS/Android) ⑤送⾦履歴保存 ※任意実装 ※送⾦の受け取り確認やPush通知はスコープ外