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
150
問題解決に役立つ数理工学
recruitengineers
PRO
13
2.8k
Curiosity & Persistence
recruitengineers
PRO
2
200
結果的にこうなった。から見える メカニズムのようなもの。
recruitengineers
PRO
1
420
成長実感と伸び悩みからふりかえる キャリアグラフ
recruitengineers
PRO
1
200
リクルートの オンプレ環境の未来を語る
recruitengineers
PRO
3
370
LLMのプロダクト装着と独自モデル開発
recruitengineers
PRO
1
380
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 ビジネス編
recruitengineers
PRO
3
210
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 技術編
recruitengineers
PRO
2
270
Other Decks in Technology
See All in Technology
ビジネス職が分析も担う事業部制組織でのデータ活用の仕組みづくり / Enabling Data Analytics in Business-Led Divisional Organizations
zaimy
1
190
United Airlines Customer Service– Call 1-833-341-3142 Now!
airhelp
0
170
shake-upを科学する
rsakata
6
700
AWS認定を取る中で感じたこと
siromi
1
200
オーティファイ会社紹介資料 / Autify Company Deck
autifyhq
10
130k
NewSQLや分散データベースを支えるRaftの仕組み - 仕組みを理解して知る得意不得意
hacomono
PRO
3
180
CDK Vibe Coding Fes
tomoki10
0
170
[SRE NEXT] ARR150億円_エンジニア140名_27チーム_17プロダクトから始めるSLO.pdf
satos
0
160
60以上のプロダクトを持つ組織における開発者体験向上への取り組み - チームAPIとBackstageで構築する組織の可視化基盤 - / sre next 2025 Efforts to Improve Developer Experience in an Organization with Over 60 Products
vtryo
2
450
LLM時代の検索
shibuiwilliam
2
410
開発生産性を測る前にやるべきこと - 組織改善の実践 / Before Measuring Dev Productivity
kaonavi
14
6.3k
データ基盤からデータベースまで?広がるユースケースのDatabricksについて教えるよ!
akuwano
3
130
Featured
See All Featured
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.9k
Statistics for Hackers
jakevdp
799
220k
The Language of Interfaces
destraynor
158
25k
A Tale of Four Properties
chriscoyier
160
23k
Into the Great Unknown - MozCon
thekraken
40
1.9k
Rebuilding a faster, lazier Slack
samanthasiow
83
9.1k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
181
54k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
980
Designing for Performance
lara
610
69k
The Cost Of JavaScript in 2023
addyosmani
51
8.5k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Testing 201, or: Great Expectations
jmmastey
43
7.6k
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通知はスコープ外