Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Stripe SSoT をするべきか否か
Search
acomagu
December 19, 2024
0
55
Stripe SSoT をするべきか否か
241219 JP_Stripes 東京 Vol.22 2024年振り返り & Tech Deep Dive
acomagu
December 19, 2024
Tweet
Share
More Decks by acomagu
See All by acomagu
Payment Records API を使って地域通貨を Stripe Dashboard に統合してみた
acomagu
0
29
Restate x Stripe: 安心して眠れる決済システムを目指して
acomagu
0
2
JP_Stripes: リコンサイル(突合処理)のテスト
acomagu
0
100
「境界付けられたコンテキスト間の関係」についてもっと語ろう
acomagu
0
99
地方 MaaS 事例: アプリの進化に伴って変化してきた Stripe 利用方法
acomagu
0
360
Stripe リコンサイルの勘所
acomagu
0
500
CDK 一発で全てのエラーログを Slack に流す
acomagu
0
2.2k
AWS CDK を支える Constructs について
acomagu
0
180
DDDとは結局何なのか
acomagu
0
370
Featured
See All Featured
Testing 201, or: Great Expectations
jmmastey
46
7.8k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
54k
Automating Front-end Workflow
addyosmani
1371
200k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.1k
Done Done
chrislema
186
16k
Designing Experiences People Love
moore
142
24k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
140
34k
Side Projects
sachag
455
43k
GraphQLとの向き合い方2022年版
quramy
49
14k
Fireside Chat
paigeccino
41
3.7k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
17k
jQuery: Nuts, Bolts and Bling
dougneiner
65
8k
Transcript
データは Stripe に寄せるべきか 自前の DB に持つべきか それが問題だ 241219 JP_Stripes 東京
Vol.22 2024年振り返り & Tech Deep Dive 株式会社デザイニウム @acomagu
Stripe で SSoT してますか?
文脈: 弊社では電子チケットを売っています
文脈: 現状のシステム構成 - Purchase には購入の状態のほかに、 「承認」「未承認」のような状態もある。 これは一部ホテルのチケット等で、購入 後に空き室を確認して「承認」するという ユースケースのため (ここは
Stripe を使っていない) - 突合処理は不整合の種類によって双方 向に調整が行われる (この突合処理がツラい...!)
きっかけ Stripe SSoT … 購入状態を Stripe だけに持たせて、ユーザーからアクセスがあるたび に購入状態を Stripe に取りに行く実装方法
(チケッティングシステムは以前この実装方法だったが、主にパフォーマンスを理由に現 在の形に移行した)
きっかけ
きっかけ SSoT をもっと考えてみることにした
CQRS とは? 「更新系のモデルとクエリ系のモデルを分離する」こと。(分けたモデルを必ずしもそれぞ れ DB に保存する必要はない) Martin Fowler: 「情報を読み込むときには、情報を書き込むときと別のモデルを利用す
る」「恐らく別々のハードウェア(=別サービス)で」 データ指向アプリケーションデザイン: Event Sourcing の文脈で「Event に対する複数の View を持つこと」
パターン1: Stripe を SSoT とする ES - 一番単純だと思う形式 - 完全に
Stripe のみを Event Source とすることで、自分で Event 履歴用 DB を用意する 必要が無い - 全ての業務データを Stripe に 入れる必要がある?
パターン2: Stripe Event を受け取る独自 ES • Stripe 以外からも Event を発行したい場合はこ
うする必要がある • 独自 ES にどの Stripe のイベントを含めるか? • Stripe の Event をどのくらい改変するか? ◦ 改変するほどバグが入り込む余地が大きくなる • Event を受け取ったときの副作用の実行につい てかなり大がかりな仕組みが必要 ◦ 決済が完了したとき「キャプチャしてメールを送る」とい う2つの副作用を実行したいとしたら、どうする?
パターン3: ES は辞める - Stripe からのコマンドとユーザーから直接の コマンドを同等に扱い、Event Sourcing はし ない
- 現状のうちのシステムに近い
これらは本当に SSoT なのか? SSoT ってなんだっけ: Truth(正)とする部分が「一つ」であること
パターン1: Stripe を SSoT とする ES 正の部分
パターン2: Stripe Event を受け取る独自 ES 正の部分
パターン3: ES は辞める 正の部分
そもそもなぜ SSoT が良かったのか? 不整合が起きない!
そもそもなぜ SSoT が良かったのか? 不整合が起きない! Single Source of Truth …
正(Truth)の部分が一つだから不整合が起きない
そもそもなぜ SSoT が良かったのか? 不整合が起きない! Single Source of Truth …
正(Truth)の部分が一つだから不整合が起きない つまり「正の部分を減らしていく」方向で考えればいい
パターン2: Stripe Event を受け取る独自 ES
パターン2: Stripe Event を受け取る独自 ES 正の部分
パターン3: ES は辞める
パターン3: ES は辞める 正の部分
パターン3: ES は辞める 正の部分 Stripe の「正」の部分を1つにしていく
現状の弊社のシステムはどうするべき?
現状の弊社のシステムはどうするべき?
まとめ - 突合処理(リコンサイル)はしんどい - パフォーマンスが問題にならないなら、毎度 Stripe からデータを取ってきた方がい い - 「どこを正とするか」が一番大切
そして、「正」となる部分を減らしていく - 購入情報とビジネスロジックが結合していて SSoT は難しいと思えても、丁寧に分 離することでもしかしたら Stripe のデータは Stripe 側を正とすることができるかもし れない...? - みなさんの意見めちゃ聞きたいです!