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

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

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

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

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

購買サービスがユーザー情報を見るパターン
ドメインサービス間の通信はダメ => 購買サービスがユーザーデータを参照する
- Pros: サービスを新しく増やさないで済む
- Cons: せっかく分割したデータベースがまたサービスで共有される。
購買履歴の機能を独立させる
- Pros: DBに対して更新操作を持つサービス(ここでは購買サービス)が他のデータベースを参照することは避けられる
- Cons: 結局データベース共有されてる？ / サービスが乱立してサービスベースアーキテクチャから外れそう
ファサードを挟む
- Pros: 既存の機能を有効活用できそう
- Cons: ファサードのコレジャナイ感
データベースを再統合
なさそう
サービスを再統合
なさそう
まとめ
参照操作だけならデータベース共有してもOK、ただし更新系はデータベースがサービスを共有しないように頑張る。が現実的な落としどころ？
- 購買サービスがユーザーDBのリードレプリカやミラーリングを参照する
- 参照のみする購買履歴サービスを作成する

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

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

気になれば考える。