複数のアプリを組み合わせてデータ統合を簡素化するのはいつですか？

Question

短縮版：

複数のチームがそれぞれ複数のアプリを開発しています。彼らはいくつかのデータを共有する必要があります。これらのアプリを1つの大きなアプリに組み合わせて、データ統合を簡素化する必要がありますか、それとも別々に保ち、データ交換/キャッシュメカニズムを利用する必要がありますか？

より長いバージョン：

それぞれがアプリケーションのセットに取り組んでいる多くのチームがあります。これらのアプリケーションの多くは、データを共有する必要があります。 1つのオプションは、非同期メッセージングを使用して、すべての書き込みが発生する1つのレコードシステムを持つことと、そのデータを必要な他のシステムにブロードキャストすることです。これらのシステムは、必要なデータビットを読み取り専用キャッシュ（データベース内）に保存します。

このレイアウトの利点は、1つのシステムが他のシステムに影響を与えることなく爆破できることです。また、個々のチームが個々のアプリケーションで作業しやすくなります。これにより、リリースのスケジューリングが簡単になり、コードベースが小さいようになります。

別のオプションは、これらのアプリがあまりにも多くのデータを共有し、メッセージング/キャッシュからのオーバーヘッドが高すぎることを決定することです。この場合、これらの3つのアプリケーションを1つの大きなアプリにマージすることを決定できます。統合をアプリの個々のモジュールのサービス/トランザクションレイヤーに移動するため、データ統合の問題を完全に排除します。言い換えれば、MygiantAppは、他のモジュールのトランザクションサービスAPIを介して互いに話すさまざまなモジュールに分割される可能性があります（JAR、アプリコンテキストなど）。私たちの場合、WebサービスやAsyncメッセージングの代わりにメソッドの呼び出しを使用して、Springをサービスバスのように使用します。

この2番目のオプションはデータ統合を簡素化しますが、開発を複雑にします。これで、Xチームは同じコードベースで作業する必要があります。これは、ブランチ、継続的な統合、個別のライブラリ/コンテキストなどを使用することで多少緩和できますが、結局のところ、それは私たち全員が構築している1つの嘆かわしいアーティファクトです。また、1つのチームの間違いは、アプリ全体に簡単に広がることができます。ヒープを吹き飛ばす1つのアプリはすべてを倒す可能性があります。

ソリューション＃1を使用するタイミングとソリューション＃2をいつ使用するかをどのように決定しますか？

Answer 1

私はこれを別の答えにしました。その焦点は私の最初のものとはまったく異なるからです。

あなたは物事を考えていて、あなたの問題と解決策の両方をよく把握しているように聞こえます。あなたの重要な質問（私が思う）に別の亀裂を持ってみましょう...

どうやって決めますか...

基本に戻る：あなたが真実であると知っていることから始めてください。
あなたのチームの関連する人々とホワイトボードワークショップを持ってください。

• 関連する制約のリストを作成します。
• 不要な結果（単一の大きな管理不可能なアプリケーションなど）をリストします。
• また、推奨されますが、おそらく不可欠ではありません。リスクと潜在的な影響を特定します（制約または望ましくない結果の一部として）。
• 必要な結果（データの共有、簡単な展開など）をリストします。
• 望ましいと望ましくない結果（非常に重要な）を優先し、議論の過程で変化しても驚かないでください。

この情報は、議論と衰弱のためのフレームワークの確立を開始するのに十分なはずです。

また、このワークショップの前にできる余分なこともあります（または、あなたの状況の政治的および社会的ダイナミクスに応じてその一部として）。

• システムの目標を特定します - 「ビジネス」の意味と「建築」の意味の両方。 （ヒント：2つは整列する必要があります - または少なくとも競合しないでください）。
• システムまたはあなたのビジネスに明確に定義されたビジョンがある場合 したほうがいい 助けてください（しかし、これらは常に存在するわけではなく、良いものはさらにまれであることに留意してください）。
• 取り組んでいるシステムのビジネス /戦略計画を参照してください - そして、市場、動向などを考慮してください。将来のアプリケーションに何が起こると思いますか？アーキテクチャに先を考えています そうではありません コードレベルでのYagniと同じであり、将来を慎重に検討することで、現在作っている巣に影響を与える可能性があります。

Answer 2

こんにちは - 答えたい正確なポイントをカバーしているかどうかはわかりませんが、それはスタートです。必要に応じて説明を求めてください。それに応じて答えを更新します。

の面では データ管理 あなたは一緒に考え始めたいかもしれません マスターデータ管理 線。頭に浮かぶ最初の考えは、あなたが一貫性がないことを望んでいないということです 参照データ;これは、データの単一の共有インスタンスを使用することをお勧めします。あるいは、そのデータの周りの管理プロセスと管理プロセスが明確であると仮定して、複数のコピーを使用することもできます。

の面では 統合, 、再利用は、さまざまなシステムの非機能要件に依存します。単一の共有サービスを使用すると、データを簡単に管理できます（心配するコピーが1つしかないということですが）が、ボトルネックになる可能性があることを意味します。さらに、「チェーンで最も弱いリンク」ルールが適用されます - 共有サービスがダウンした場合の影響は何ですか？

可能なソリューションオプション

詳細がなければ何を推奨するかを知るのは難しいですが、私の考えは次のとおりです。

• 3つのアプリを分離してください。
• 共有データには1つの共有サービスを使用します。
• 共有データへのアクセスは、「サービス」を介して行うことができます。これにより、最大のコントロールとオプションが得られます。
• 共有サービスは、単一のインスタンスとして存在する可能性があります - または - 展開されたサービスの再生インスタンス（ただし、DBの1つのインスタンスのみ）がある場合があります。

重要なポイントは、他のアプリに影響を与えることなく共有サービスを抽象化できるはずです。特に、Uberアプリを作成することを考えてはいけません。

もう1つ - ビジネスの意味で1つの「サービス」があることを考えることは、技術的にそれを暴露し、消費する複数の方法を排除することではありません。

Answer 3

並行性、トランザクションなどについて考えましたか...

あなたの要件はわかりませんが、この問題に正しい方法で取り組み、中央の「リポジトリ」を使用して共有データを管理する時が来たように感じます。