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
acomagu
December 19, 2024
0
22
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
JP_Stripes: リコンサイル(突合処理)のテスト
acomagu
0
54
「境界付けられたコンテキスト間の関係」についてもっと語ろう
acomagu
0
51
地方 MaaS 事例: アプリの進化に伴って変化してきた Stripe 利用方法
acomagu
0
180
Stripe リコンサイルの勘所
acomagu
0
350
CDK 一発で全てのエラーログを Slack に流す
acomagu
0
2k
AWS CDK を支える Constructs について
acomagu
0
150
DDDとは結局何なのか
acomagu
0
250
API Gateway HTTP API について
acomagu
0
120
JP_Stripes: 一貫性に寄与する設計
acomagu
0
83
Featured
See All Featured
Typedesign – Prime Four
hannesfritz
40
2.4k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
32
2.7k
Testing 201, or: Great Expectations
jmmastey
40
7.1k
The Cost Of JavaScript in 2023
addyosmani
45
7k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Fashionably flexible responsive web design (full day workshop)
malarkey
405
66k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
132
33k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.9k
Optimizing for Happiness
mojombo
376
70k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.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 側を正とすることができるかもし れない...? - みなさんの意見めちゃ聞きたいです!