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.5k
実践オブジェクト指向設計事前課題
2023年度リクルート エンジニアコース新人研修の講義資料です
Recruit
PRO
August 10, 2023
Tweet
Share
More Decks by Recruit
See All by Recruit
Flutterによる 効率的なAndroid・iOS・Webアプリケーション開発の事例
recruitengineers
PRO
0
73
VPC Traffic Mirroring とOSS を利⽤した ネットワークフォレンジック基盤の構築・運⽤
recruitengineers
PRO
1
44
スタサプ ForSCHOOLアプリのシンプルな設計
recruitengineers
PRO
3
1k
リクルート流データ基盤塾~鶴谷と学ぶ~
recruitengineers
PRO
5
240
『SUUMO』 スマホサイト デザインリニューアルへの挑戦
recruitengineers
PRO
5
340
『リクルートダイレクトスカウト』 のリニューアルから振り返る: ビジョンドリブンの可能性
recruitengineers
PRO
3
310
負債あるモノリスのオブザーバビリティに組織で向き合う
recruitengineers
PRO
9
400
あなたの知らないiOS開発の世界
recruitengineers
PRO
4
330
大規模プロダクトにおける組織作りと技術ポートフォリオマネジメント
recruitengineers
PRO
4
490
Other Decks in Technology
See All in Technology
iOS/Androidで同じUI体験をネ イティブで作成する際に気をつ けたい落とし穴
fumiyasac0921
1
110
B2B SaaSから見た最近のC#/.NETの進化
sansantech
PRO
0
670
Evangelismo técnico: ¿qué, cómo y por qué?
trishagee
0
350
誰も全体を知らない ~ ロールの垣根を超えて引き上げる開発生産性 / Boosting Development Productivity Across Roles
kakehashi
1
220
信頼性に挑む中で拡張できる・得られる1人のスキルセットとは?
ken5scal
2
530
隣接領域をBeyondするFinatextのエンジニア組織設計 / beyond-engineering-areas
stajima
1
270
Lambda10周年!Lambdaは何をもたらしたか
smt7174
2
110
テストコード品質を高めるためにMutation Testingライブラリ・Strykerを実戦導入してみた話
ysknsid25
7
2.6k
データプロダクトの定義からはじめる、データコントラクト駆動なデータ基盤
chanyou0311
2
280
[FOSS4G 2019 Niigata] AIによる効率的危険斜面抽出システムの開発について
nssv
0
310
B2B SaaS × AI機能開発 〜テナント分離のパターン解説〜 / B2B SaaS x AI function development - Explanation of tenant separation pattern
oztick139
2
220
SREによる隣接領域への越境とその先の信頼性
shonansurvivors
2
510
Featured
See All Featured
StorybookのUI Testing Handbookを読んだ
zakiyama
27
5.3k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
42
9.2k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.7k
How to Think Like a Performance Engineer
csswizardry
20
1.1k
It's Worth the Effort
3n
183
27k
GitHub's CSS Performance
jonrohan
1030
460k
Building Adaptive Systems
keathley
38
2.3k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5k
Gamification - CAS2011
davidbonilla
80
5k
GraphQLの誤解/rethinking-graphql
sonatard
67
10k
Producing Creativity
orderedlist
PRO
341
39k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
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通知はスコープ外