3

互いにデータを必要とすることが多いが、必ずしも同じカテゴリに属していない疎結合システムを設計するにはどうすればよいでしょうか?

たとえば、古いペット ショップの例をさらに一歩進めて、ペット ショップのフランチャイズを作成してみましょう。各ペットショップには、連絡先情報、プロモーション、現在の在庫を掲載した独自の Web サイトがあります。

フランチャイズ オーナーは、すべてのフランチャイズ ペット ショップのリストと、連絡先情報、および場合によっては企業サイトで利用できる数枚の写真を掲載したいと考えています。彼らは、この情報を更新できるようにしたいと考えており、更新があれば自動的に双方向にプッシュされます。また、自動化された方法ですべての店舗のサイトにプロモーション情報を提供したいと考えています。

したがって、この例では、在庫リストは店舗によって「所有」され、連絡先情報は両方のエンティティによって部分的に「所有」され、プロモーション情報は HQ によって「所有」されます。任意の理由により、このすべてのデータを同じ場所に保存することはできません。

このような状況に対処するためのベスト プラクティスや一般的な戦略はありますか?

4

4 に答える 4

1

私の理解では、この種の問題はほとんどの場合、「データ フェデレーション」と呼ばれる手法を使用して対処されます。独立したエンティティは独立して機能しますが、システム全体を見る能力を提供する傘のようなエンティティが存在します。

役に立つかもしれない記事は次のとおりです: http://www.soamag.com/I22/0908-1.asp

アーキテクチャを計画するときは、参加者の 1 人が利用できない場合に何が起こるかを念頭に置いてください。たとえば、バッチ プロセスとして、または参照データが変更されたときに、プロモーション情報をすべての店舗に複製することをお勧めします。そうすれば、ネットワークがダウンした場合でも、個々のストアにはまだプロモーション情報があり、機能することができます。

于 2008-11-16T20:05:35.943 に答える
1

私はその問題について考えてきましたが、クラス間の関係は文脈によって決まるということで表現しています。また、クラス間のグローバルな静的関連付け (固有の結合) を前提とするモデルには問題があります。

私が好んで使用するもう 1 つの例は、Products です。

製品はさまざまな役割を果たすことができます。これは、Customer に関連付けられた Order に関連付けられた OrderItem に関連付けられています。

ベンダーから提供されます。

カタログにあり、おそらくセクションとページごとです。

これは、複数のベンダーから入手できるバイヤーの責任です。

この複雑さを簡単に処理できることが、リレーショナル データ モデルの基本的な利点です。そして、OOP に関してうまく処理されているのを見たことがありません。

余談ですが、別の ORM (Object Role Modeling、VisioModeler、InfoModeler などを参照) があり、リレーショナル側から問題を非常に便利に調べます (IMHO)。

(CRUD ジェネレーター、ActiveRecords などを使用して) データベースの関係性から自分自身を分離すると、この重要な側面が隠されます。（LINQにも同じ問題があり、基本的な結合の問題が発生していると思いますが、まだ完全には解決していません。）

注意すればうまくいくと思いますが、カップリングを設計に組み込むのは簡単になります。特に、データベースからアプリケーションの残りの部分に戻るのではなく、他の方向に戻る場合です。

于 2008-11-16T20:49:22.500 に答える
1

この場合、SOA が役立つようです。具体的には、 Bill PooleとUdi Dahanによって説明されている、pub-sub 非同期イベントベースの実装を使用したビジネスレベルの SOA を意味します。

あなたは、フランチャイズと販売という、異なる所有者を持ついくつかのビジネス機能について説明しました。それらの間の疎結合を実現したい。

SOA の方法では、フランチャイズ サービスと、店舗ごとに 1 つずつ、販売サービスのいくつかのインスタンスを定義します。ショップは最初は非常に似ていますが、個別に進化する可能性があります。

次に、これらのサービスで発生する相互に関心のあるビジネス イベントを定義します。フランチャイズ サービスは、すべてのセールス サービスがサブスクライブする NewPromotion イベントを発行できます。このイベント メッセージには、プロモーションに関するすべての詳細が含まれており、消費者は必要なものを選択します。販売サービスは、フランチャイズによって消費される ContactDetailsChanged イベントを発行します。

各サービスには、内部に独自の多層実装があり、データベース、顧客向け Web サイト、他のシステムとのプライベート統合ポイントなどを完備しています。

各サービスは、関心のあるすべてのデータ (在庫リスト、連絡先情報、プロモーション情報) を適切な形式で非公開に保存します。1 つのサービスの情報に対する更新は、イベントを通じて他のサービスに伝達されます。

実装側では、 NServiceBusなど、信頼性の低いインターネットを介した永続的なメッセージングをサポートする、サービス間のある種のサービス バスが必要です。WebServices(tm) は必要ありません。

サービスは、コントラクト (発行するメッセージとエンドポイントの説明) のみを共有し、内部表現を独立して進化させることができるため、実装では疎結合です。また、それらは時間的にも疎結合です。これは、インターネット経由でタイムアウトになる可能性のある同期要求を相互に送信しないためです。すべてのメッセージングは​​、インフラストラクチャ (サービス バス) によって処理されます。

お役に立てれば ：）

于 2008-11-27T13:14:30.277 に答える
0

上記の提案されたソリューション (SOA を使用) にほぼ同意します。アプリケーションの複雑さによっては、ESB が適切なアプローチになる場合があります。しかし、ESB はフットプリントが大きく、ほとんどの実際のアプリケーションに不必要な複雑さをもたらすと思います。

しかし、私見では、優れたアーキテクチャは、アーキテクチャや設計を大幅に変更することなく、アプリケーション サーバーに簡単に適応できるはずです。

Java ベースの中規模から大規模な n 層アプリケーションを想定して、中間層と EIS 層に関する私の提案を次に示します。

  1. 各サブシステム実装を分離し、サービス インターフェイスを介してその機能を公開し、直接使用または参照されないように実装を非表示にします。

  2. サブシステムごとに 1 つの JAR (または EAR) ファイルを作成し、上記で特定したサブシステム/JAR 間の実行時およびコンパイル時の依存関係を判別します。

  3. サービス インターフェイス メソッドとサブシステムの依存関係の正確な粒度を決定するために、十分な時間を費やしてください。

  4. この作業中に、モジュールごとに DAO レイヤー (DB が含まれていると仮定) を識別し、サブシステムごとにデータベース テーブルを分離するようにしてください。

Web 層については、サブシステムごとにプレゼンテーション レイヤーを分割して、上記と同じことを試みます。サブシステムごとに 1 つの WAR ファイルを作成します。必要に応じて、プレゼンテーション レイヤー WAR を上記の適切な EAR ファイルに配置してみてください。

上記のアーキテクチャを適切に検証するには、(適切なマニフェスト ファイルを作成した後) 各サービスを OSGi サービスとして使用して、これを OSGi にデプロイします。

必要に応じて、これらのサブシステム間でもイベントベース/非同期通信をセットアップできることに注意してください。

これにより、サブシステムを分割し、それらをサーバーの異なるファームに展開して、スケーラビリティの機会を向上させることができます。

幸運を..！

于 2008-12-08T04:30:28.893 に答える