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
Stripe SSoT をするべきか否か
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
acomagu
December 19, 2024
83
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Stripe SSoT をするべきか否か
241219 JP_Stripes 東京 Vol.22 2024年振り返り & Tech Deep Dive
acomagu
December 19, 2024
More Decks by acomagu
See All by acomagu
Payment Records API を使って地域通貨を Stripe Dashboard に統合してみた
acomagu
0
62
Restate x Stripe: 安心して眠れる決済システムを目指して
acomagu
0
16
JP_Stripes: リコンサイル(突合処理)のテスト
acomagu
0
130
「境界付けられたコンテキスト間の関係」についてもっと語ろう
acomagu
0
170
地方 MaaS 事例: アプリの進化に伴って変化してきた Stripe 利用方法
acomagu
0
510
Stripe リコンサイルの勘所
acomagu
0
540
CDK 一発で全てのエラーログを Slack に流す
acomagu
0
2.3k
AWS CDK を支える Constructs について
acomagu
0
190
DDDとは結局何なのか
acomagu
0
450
Featured
See All Featured
Navigating the moral maze — ethical principles for Al-driven product design
skipperchong
2
390
Agile Actions for Facilitating Distributed Teams - ADO2019
mkilby
0
210
How To Speak Unicorn (iThemes Webinar)
marktimemedia
1
490
GitHub's CSS Performance
jonrohan
1033
470k
Avoiding the “Bad Training, Faster” Trap in the Age of AI
tmiket
0
180
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
Are puppies a ranking factor?
jonoalderson
1
3.6k
The Organizational Zoo: Understanding Human Behavior Agility Through Metaphoric Constructive Conversations (based on the works of Arthur Shelley, Ph.D)
kimpetersen
PRO
0
360
Agile that works and the tools we love
rasmusluckow
331
21k
Stop Working from a Prison Cell
hatefulcrawdad
274
21k
Building Flexible Design Systems
yeseniaperezcruz
330
40k
Why You Should Never Use an ORM
jnunemaker
PRO
61
9.9k
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 側を正とすることができるかもし れない...? - みなさんの意見めちゃ聞きたいです!