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.8k
実践オブジェクト指向設計事前課題
2023年度リクルート エンジニアコース新人研修の講義資料です
Recruit
PRO
August 10, 2023
Tweet
Share
More Decks by Recruit
See All by Recruit
Javaで作る RAGを活用した Q&Aアプリケーション
recruitengineers
PRO
1
140
問題解決に役立つ数理工学
recruitengineers
PRO
12
2.8k
Curiosity & Persistence
recruitengineers
PRO
2
200
結果的にこうなった。から見える メカニズムのようなもの。
recruitengineers
PRO
1
410
成長実感と伸び悩みからふりかえる キャリアグラフ
recruitengineers
PRO
1
190
リクルートの オンプレ環境の未来を語る
recruitengineers
PRO
3
350
LLMのプロダクト装着と独自モデル開発
recruitengineers
PRO
1
360
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 ビジネス編
recruitengineers
PRO
3
200
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 技術編
recruitengineers
PRO
2
270
Other Decks in Technology
See All in Technology
生まれ変わった AWS Security Hub (Preview) を紹介 #reInforce_osaka / reInforce New Security Hub
masahirokawahara
0
360
GitHub Copilot の概要
tomokusaba
1
150
MySQL5.6から8.4へ 戦いの記録
kyoshidaxx
1
300
Tech-Verse 2025 Keynote
lycorptech_jp
PRO
0
1.3k
AI専用のリンターを作る #yumemi_patch
bengo4com
3
1.9k
Zephyr RTOSを使った開発コンペに参加した件
iotengineer22
0
130
モバイル界のMCPを考える
naoto33
0
350
Github Copilot エージェントモードで試してみた
ochtum
0
130
整頓のジレンマとの戦い〜Tidy First?で振り返る事業とキャリアの歩み〜/Fighting the tidiness dilemma〜Business and Career Milestones Reflected on in Tidy First?〜
bitkey
0
220
作曲家がボカロを使うようにPdMはAIを使え
itotaxi
0
390
使いたいMCPサーバーはWeb APIをラップして自分で作る #QiitaBash
bengo4com
0
1.2k
Core Audio tapを使ったリアルタイム音声処理のお話
yuta0306
0
150
Featured
See All Featured
Testing 201, or: Great Expectations
jmmastey
42
7.6k
Optimizing for Happiness
mojombo
379
70k
How GitHub (no longer) Works
holman
314
140k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.5k
Documentation Writing (for coders)
carmenintech
72
4.9k
Navigating Team Friction
lara
187
15k
Done Done
chrislema
184
16k
Building a Modern Day E-commerce SEO Strategy
aleyda
42
7.4k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.7k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
720
Scaling GitHub
holman
459
140k
The Language of Interfaces
destraynor
158
25k
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通知はスコープ外