Application_1とApplication_2の2つのWebアプリケーションがあります。
Application_2
には、頻繁に変更されないtable_2
という名前のデータベーステーブルがあり、Application_1
からアクセスする必要があります。
table_2
にApplication_1
テーブルを作成し、ETLタスクで更新することは意味がありますか?
簡単な解決策は、REST API in Application_2
)を介してデータを公開することですが、これにより両方のアプリケーション間の分離が解除され、Application_1に新しい障害点が導入されます。
質問にSOAのタグを付けたので、正しい答えはサービスインターフェースを使用しているのではないかと考えています。そのようなサービスインターフェースはデータを公開するべきではありませんが、あるアプリケーションによって公開され、他のアプリケーションによって消費されるコントラクトとして提供したい機能です。
質問は要約で尋ねられるため、このコントラクトは、非常に具体的なルックアップへの回答の提供から、消費者に変更を通知するイベントストリームまで、さまざまな範囲に及ぶ可能性があります。
どちらのアプリケーション(つまり、サービスインターフェイスの片側または両側)でも、必要に応じてキャッシング(テーブルのコピー)を利用できますが、キャッシングは時期尚早に適用すべきではない最適化です。
どちらの方法でも、これらのアプリケーションは結合されています。また、提案するETLジョブはアプリケーションを結合し、適切に設計されたサービスインターフェイスよりもアプリケーション間のコントラクトがよく理解されない可能性があります。
最善の方法は、REST apiを作成することですが、スケジュールされたジョブでデータをコピーします。データベースを共有することは、ソリューション間で常に回避する必要があります。歯ブラシと接続文字列は共有しないことを忘れないでください。
Dbの内部動作を公開することで、両方のアプリのリズムを相互にロックし、どちらもどちらも内部動作をより適切なテクノロジーに変更することができなくなります。残りのAPIはこの問題を回避します。
これを行う1つの方法は、APIをApplication_3_API_service
とApplication_1
の両方に公開するApplication_2
を作成することです。
現在Application_1
およびApplication_2
で読み取り/書き込み操作を行っているすべてのサービスは、Application_3_API_service
で公開されているさまざまなエンドポイントにヒットするようになりました。
データベース接続を持つ唯一のアプリケーションはApplication_3_API_service
です。
+---------------+ +---------------+
| Application_1 | | Application_2 |
+---------+-----+ +--------+------+
| |
+---------v--------------------v------+
| Application_3_API_service |
+-------------------------------------+
提示された質問は、あなたの サービス境界が間違っている であることを示しています。サービスは自己完結型である必要があり、データを公開したり、他のサービスがそのデータを操作したりしないようにする必要があります。代わりに、サービスは動作を公開する必要があります-他のオブジェクトと同じように。
本当の問題は サービスの境界を特定する方法 です。これにより、結果として得られるサービスは疎結合され、非常にまとまりがあり、自律的になります。
ですから、ここでそれを取り上げます。最初に ビジネス機能マッピングテクニック を使用して問題スペースを分解し、次に1:1の関係でテクニカルサービスをマッピングすることは有益であることがわかりました。したがって、私のサービスは本質的に自律的でまとまりがあり、厳密に定義された単一の真の情報源を持っています。
ただし、イベントを介してデータを共有する場合は注意してください。必要な場合は、境界が間違っている可能性があります。 Web(またはその他の)インターフェースに必要だと思われる場合は、 フロントエンドのバックエンド が適しています。イベントはトリガー用です sagas 、データ共有用ではありません。
たぶん この例 はあなたにとって何らかの興味があるでしょう。