2

短縮版：

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

長いバージョン：

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

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

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

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

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

4

3 に答える 3

1

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

データ管理の観点から、マスターデータ管理の方針に沿って考え始めることをお勧めします。頭に浮かぶ最初の考えは、一貫性のない参照データは必要ないということです。これは、データの単一の共有インスタンスを使用することを示唆します。あるいは、そのデータの管理および管理プロセスが非常に明確であると仮定して、複数のコピーを持つことができます。

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

考えられる解決策の選択肢

これ以上の情報がないと何をすすめるべきかを知るのは難しいですが、私の考えは次のとおりです。

  • 3つのアプリを分けてください。
  • 共有データには単一の共有サービスを使用します。
  • 共有データへのアクセスは「サービス」を介して行うことができます。これにより、ほとんどの制御とオプションが提供されます。
  • 共有サービスは単一のインスタンスとして存在する場合があります-または-サービスの複数のインスタンスがデプロイされている場合があります（ただし、DBのインスタンスは1つだけです）。

重要な点は、他のアプリに影響を与えることなく共有サービスを抽象化できる必要があるということです。特に、uberアプリの作成を考えるべきではありません。

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

于 2010-10-05T21:59:50.200 に答える
1

その焦点は私の最初のものとはかなり異なるので、私はこれを別の答えに入れました。

あなたは物事を熟考し、問題と解決策の両方をよく理解しているように思えます。あなたの重要な質問（私が思うに）に別の亀裂を入れさせてください...

どのように決定しますか...

基本に戻ります。真実であることがわかっていることから始めます。
チームの関係者とホワイトボードワークショップを開催します。このワークショップでは、次のことを行う必要があります。

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

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

このワークショップの前に（または状況の政治的および社会的ダイナミクスに応じてその一部として）実行できる追加のこともいくつかあります。

  • 「ビジネス」の意味と「アーキテクチャ」の意味の両方で、システムの目標を特定します。（ヒント：2つは整列する必要があります-または少なくとも競合しないでください）。
  • 役立つはずのシステムまたはビジネスの明確に定義されたビジョンがある場合（ただし、これらは常に存在するとは限らず、優れたビジョンはさらにまれであることに注意してください）。
  • 作業中のシステムのビジネス/戦略計画を参照し、市場やトレンドなどを検討してください。将来、アプリケーションに何が起こる可能性があると思いますか？アーキテクチャ的に先を見据えることは、コードレベルでのYAGNIと同じではありません。将来を慎重に検討することは、現在行っている決定に影響を与える可能性があります。
于 2010-10-06T20:40:36.553 に答える
0

並行性、トランザクション、...について考えたことはありますか？

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

于 2010-10-04T14:29:43.330 に答える