第7回 Software Architecture: The Hard Parts 読書会@リモート

development javaeestudy

第7回 Software Architecture: The Hard Parts 読書会 - connpass

参加者トピック

ディスカッション

9. Data Ownership and Distributed Transactions

  • 「複数のサービスが同じデータベーススキーマにアクセスするのはOK、1つのサービスが複数のデータベーススキーマにアクセスするのはNG」
    • そういう割り切りありだなって思った
  • 普通はテーブルの所有権って考えるものなのか
    • モノリシックアプリケーションならともかく、マイクロサービスアーキテクチャを考えているなら考えるものだと思う
    • 仕事ではサービス=プロジェクトとして管理している
      • 誰が所有してるかはすぐ分かるようになっていて欲しい
  • audit だけ用途が違うから、別に複数のサービスが書き込んでいるとしても、複雑になってないと思ってしまった
  • Q 所有権って概念って一般的？
    • A モノリシックサービスが分解される過程で、データアクセス元のサービスを意識するようになった結果生じた概念では？
    • ...自分もそんな気はする。モノリスなサービスしか経験してないので誰が所有しているかはっきりしなくてもいい現場感？的な。
  • 共同所有権シナリオ、いい思い出がないので感情的に否定しがち
  • 経験談
    • Inventory Serviceで管理する在庫は自社在庫じゃない場合があった
    • 他社の在庫管理システムで扱ってる在庫の扱いが違うとかで大変

Table Split Technique

Data Domain Technique

  • どの辺がテクニックなんだろうと思ったけど、テーブルを宙に浮かせないで、境界づけられたコンテキストに納めて人間が認識できるようにするところがテクニックなのかな
  • その行を追加・更新したプログラムID、みたいな列があるのを今までのすべての会社で経験してて、ガバナンスやなって思いました

Delegate Technique

  • (全体的に)トレードオフ分析の表は、メリットとデメリットを対比してるわけでもないし、それぞれに重みがあるわけでもないし、この表だけで分析するのは難しそう
  • operational characteristics ってちょうどいい言葉(訳語)がなさそうで、「運用特性」以外の言葉が生まれて欲しい

Service Consolidation Technique

  • データの所有権を考えていたらサービスが肥大化する場合があるテクニック
    • デプロイ/リリースサイクルの向上が大正義な文脈では採用しにくいやつだ

Data Ownership Summary

  • どちらも永続化するのに、テーブルとキューで扱いが違うの面白い
    • テーブル:できるだけ境界づけられたコンテキストに配置する
    • キュー:境界づけられたコンテキストの外側に配置されている

Distributed Transactions

Eventual Consistency Patterns

Background Synchronization Pattern

  • トレードオフ
    • すべてのデータソースが結合する
      • 関連するサービスが共同所有権を持つようになってしまう
    • 境界づけられたコンテキストが守られない
      • きっかけは顧客プロファイルサービスでも、サポート契約、支払い請求について独自のビジネスルールがあるかもしれない
  • このパターンが有効な場面は、互いに通信せず、データも共有しない閉じた（自己完結した）異なる種類のシステムである。
    • 異なるサービスで同じデータを適用、参照できるのに綺麗に分離されてるってほんとかな
    • プロファイル、契約、請求が、外の世界の別々のサービスになっている様子を考えるとありそうな気がしてきました

Orchestrated Request-Based Pattern

  • 補償トランザクションで解消できなかった問題を解消するには人間の介入が必要で、redo ログ的な記録が肥大化したりするなど、重くなるのは避けられないんでしょうか？
    • 基本的にそれぞれのサービスが自身のトランザクションを補償するためのAPIを設けるはず
    • オーケストレーターはそれを呼び出すだけになるはず

Event-Based Pattern

Sysops Squad Saga: Data Ownership for Ticket Processing

  • 境界づけられたコンテキストとかドメインとかの言葉がどの文脈で使われてるかわからないので、なんか言葉に振り回されている感じがすごい
  • そのせいで、「チケット完了サービス」という単語がじわじわ面白くなってきてしまった

Chapter 10. Distributed Data Access

“分散システムにおけるデータの扱いについては、『データベースリファクタリング』の共著者であるPramod Sadalage、『Data Mesh』の刊行を控えたZhamak Dehghaniを共著者として迎え” 気合が入っている章らしいです

参考情報