サービスベースアーキテクチャ ドメインサービス間の通信は避けるべき について

ソフトウェアアーキテクチャの基礎 13章 サービスベースアーキテクチャ　で 「ドメインサービス間の通信は避けるべき」 と記載があったが、サービスベースアーキテクチャにおいてサービスまたいだデータが欲しくなったときにどういった落とし所があるか？を考えてみた。

ドメインサービス間の通信は避けるべき

データベースを分割する場合には、それぞれのデータベースが持つデータを他のドメインサービスが必要としていないことを確認する必要がある。そうすることで、ドメインサービス間の通信(サービスベースアーキテクチャでは絶対に避けるべきこと)やデータベース間のデータの重複を避けられる。

言及されている、避けるべきこと

• ドメインサービス間の通信
• データーベース間のデータの重複

ケースで考える（参照系の共有）

1. なんかECっぽいサービス
   

2. ユーザー情報と購買情報はそれぞれ独立してるから、DBも分割して良さそうと判断し分割
   

3. 購買履歴の一覧表示機能が欲しくなる
   購買サービスに作成
   

4. 購買履歴の一覧表示にユーザー情報も出したくなる
   (リアルタイムで、オンラインで画面を見たいようなケースを考える)

• 購買サービスがユーザー情報を見るパターン
  ドメインサービス間の通信はダメ => 購買サービスがユーザーデータを参照する
  

  • Pros: サービスを新しく増やさないで済む
  • Cons: せっかく分割したデータベースがまたサービスで共有される。

• 購買履歴の機能を独立させる
  

  • Pros: DBに対して更新操作を持つサービス(ここでは購買サービス)が他のデータベースを参照することは避けられる
  • Cons: 結局データベース共有されてる？ / サービスが乱立してサービスベースアーキテクチャから外れそう

• ファサードを挟む
  

  • Pros: 既存の機能を有効活用できそう
  • Cons: ファサードのコレジャナイ感

• データベースを再統合
  なさそう

• サービスを再統合
  なさそう

• まとめ
  参照操作だけならデータベース共有してもOK、ただし更新系はデータベースがサービスを共有しないように頑張る。が現実的な落としどころ？

  • 購買サービスがユーザーDBのリードレプリカやミラーリングを参照する
  • 参照のみする購買履歴サービスを作成する

ただし、どのケースでもDB分割してる時点で、オンライン処理で2つのテーブルの結合は現実的なスピードではなさそう。絶対にオンラインでリアルタイム情報を一覧表示したい。みたいな要望があった時点でなかなか厳しくなる気もする。

ケースで考える（参照系の共有その2）

• 前提
  ユーザーサービス / ポイントサービス の2つにサービス、データベースが分割されている状態

• 追加要望
  ユーザー情報画面に保持ポイントを表示したくなった場合。

=> この程度ならファサードで処理 または、ユーザーンターフェイスが別にリクエスト投げるなどでも良さそう

ケースで考える（更新系の共有）

気になれば考える。