Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
実践オブジェクト指向設計事前課題
Search
Recruit
PRO
August 10, 2023
Technology
3.1k
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
実践オブジェクト指向設計事前課題
2023年度リクルート エンジニアコース新人研修の講義資料です
Recruit
PRO
August 10, 2023
More Decks by Recruit
See All by Recruit
実体験から学ぶ分析エージェントの開発と運⽤
recruitengineers
PRO
4
1.1k
大規模フロントエンド開発におけるmonorepoという選択肢
recruitengineers
PRO
1
48
自律型 AI をセキュアに実装!Gemini と MIG で作る動的コード実行環境
recruitengineers
PRO
1
220
Google Cloud Next Tokyo 26登壇時のスクリプト
recruitengineers
PRO
0
210
つくって納得、つかって実感! 大規模言語モデルことはじめ ver2.0
recruitengineers
PRO
6
2.7k
ブラウザ研修 2026
recruitengineers
PRO
8
2k
事業価値と Engineering 2026年度版
recruitengineers
PRO
59
30k
トヨタ⽣産⽅式(TPS)⼊⾨
recruitengineers
PRO
3
1.5k
JavaScript 研修 (2026)
recruitengineers
PRO
2
930
Other Decks in Technology
See All in Technology
継続的なAIコスト最適化
bgpat
1
210
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
17
120k
More Freedom on the Same Shared GPU Cluster: A Small Team’s Experience with vCluster
nttcom
0
140
[2026-09-30]ロックンロールは鳴り止まないっ - 信頼性かまってちゃん - 「データ駆動を投げ捨ててまで。」追いかける信頼性改善に向けた取り組みの話
tosite
0
210
「Docker Desktop不要の時代」は 来たのか?
ueponx
0
170
分析AIエージェントを育てる、動く環境を育てる
codatum
0
180
全人類(ほぼ)AWS Organizations の上でAWSを利用している、その世界を知る話
htan
0
120
OSC2026on_the-world-is-waiting-for-your-voice.pdf
naruoga
0
360
FOSS4Gを活用した自治体業務DXの試み
470715
0
120
全社共通データ基盤をつくる。ソニーのDatabricks活用とデータガバナンス設計の裏側
sony
0
430
使いこなすために知っておきたい Azure SRE Agent アンチパターン
torumakabe
2
410
無理せず続ける、子育てエンジニアの学び
codmoninc
PRO
0
350
Featured
See All Featured
Being A Developer After 40
akosma
91
590k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
25
2.1k
The Art of Programming - Codeland 2020
erikaheidi
57
14k
A designer walks into a library…
pauljervisheath
211
25k
Context Engineering - Making Every Token Count
addyosmani
9
1.2k
A brief & incomplete history of UX Design for the World Wide Web: 1989–2019
jct
2
530
The Illustrated Children's Guide to Kubernetes
chrisshort
51
53k
Agile Actions for Facilitating Distributed Teams - ADO2019
mkilby
0
300
Sam Torres - BigQuery for SEOs
techseoconnect
PRO
0
570
How GitHub (no longer) Works
holman
316
150k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
508
140k
Why Mistakes Are the Best Teachers: Turning Failure into a Pathway for Growth
auna
0
320
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通知はスコープ外