Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Stripe SSoT をするべきか否か

acomagu
December 19, 2024
22

Stripe SSoT をするべきか否か

241219 JP_Stripes 東京 Vol.22 2024年振り返り & Tech Deep Dive

acomagu

December 19, 2024
Tweet

Transcript

  1. データは Stripe に寄せるべきか 自前の DB に持つべきか それが問題だ 241219 JP_Stripes 東京

    Vol.22
 2024年振り返り & Tech Deep Dive
 
 株式会社デザイニウム @acomagu

  2. きっかけ Stripe SSoT … 購入状態を Stripe だけに持たせて、ユーザーからアクセスがあるたび に購入状態を Stripe に取りに行く実装方法


    (チケッティングシステムは以前この実装方法だったが、主にパフォーマンスを理由に現 在の形に移行した)

  3. CQRS とは? 「更新系のモデルとクエリ系のモデルを分離する」こと。(分けたモデルを必ずしもそれぞ れ DB に保存する必要はない)
 
 Martin Fowler: 「情報を読み込むときには、情報を書き込むときと別のモデルを利用す

    る」「恐らく別々のハードウェア(=別サービス)で」
 
 データ指向アプリケーションデザイン: Event Sourcing の文脈で「Event に対する複数の View を持つこと」

  4. パターン1: Stripe を SSoT とする ES - 一番単純だと思う形式
 - 完全に

    Stripe のみを Event Source とすることで、自分で Event 履歴用 DB を用意する 必要が無い
 - 全ての業務データを Stripe に 入れる必要がある? 
 

  5. パターン2: Stripe Event を受け取る独自 ES • Stripe 以外からも Event を発行したい場合はこ

    うする必要がある
 • 独自 ES にどの Stripe のイベントを含めるか?
 • Stripe の Event をどのくらい改変するか?
 ◦ 改変するほどバグが入り込む余地が大きくなる 
 • Event を受け取ったときの副作用の実行につい てかなり大がかりな仕組みが必要
 ◦ 決済が完了したとき「キャプチャしてメールを送る」とい う2つの副作用を実行したいとしたら、どうする? 

  6. そもそもなぜ SSoT が良かったのか? 不整合が起きない!
 
 Single Source of Truth …

    正(Truth)の部分が一つだから不整合が起きない
 
 つまり「正の部分を減らしていく」方向で考えればいい

  7. まとめ - 突合処理(リコンサイル)はしんどい
 - パフォーマンスが問題にならないなら、毎度 Stripe からデータを取ってきた方がい い
 - 「どこを正とするか」が一番大切


    そして、「正」となる部分を減らしていく
 - 購入情報とビジネスロジックが結合していて SSoT は難しいと思えても、丁寧に分 離することでもしかしたら Stripe のデータは Stripe 側を正とすることができるかもし れない...?
 - みなさんの意見めちゃ聞きたいです!