0

私は現在、ゼロからシステムを設計することに携わっています。解決する最善の方法がわからないアーキテクチャ設計シナリオに遭遇しましたが、他の人が解決したと確信しており、おそらくパターンさえあるでしょう。それのための。

これまでの話：

プラグインとしてさまざまな機能を実装しているマルチテナント Web サイトがあり、クライアントはアプリケーションで使用するプラグインを選択します。また、各プラグインには、ユーザーがページに追加できるさまざまな「ウィジェット」を含めることができます。（たとえば、メイン画面に追加できるウィジェットが Android アプリによく付属するのと同様の考え方です）。

プラグインは、他のプラグインの有効化に依存する場合があります (たとえば、eCommerce プラグインには Payments プラグインが必要です)。また、プラグインは他のプラグインを使用して機能を強化できます (たとえば、ブログ プラグインにはコメント プラグインを使用するオプションがあり、e コマース製品でコメントを使用することもできます)。

可能な限り、各プラグインが自己完結型であり、非常に細い public インターフェイスを備えていることを望んでいます。この関心の分離により、システム全体の長期的な柔軟性と保守性が最高になると信じています。

問題：

私たちが現在知っているすべてのプラグイン (将来の要件は言うまでもなく)、およびそれらの依存関係と他のプラグインとの可能な関係をレイアウトし始めたとき、それは狂気の蜘蛛の巣に非常によく似ているようになり始めました。また、いくつかの循環参照が発生し始めました。

たとえば、Navigation Plugin は、サイトにあるページについて知る必要があります。ただし、ページにナビゲーション ウィジェットを追加することもできます。

部分的/潜在的な解決策:

各プラグインは他のプラグインから完全に分離されるべきであると考えていましたが、メッセージを介して他のプラグインから情報を取得し、通信します。これらのメッセージは、2 つの基本的なタイプに分類できます。

  • 別のプラグインからの情報のリクエスト (リクエスト / レスポンス メッセージ)
  • イベント通知 (イベント メッセージ)

これらのメッセージ タイプは両方とも、非常に単純な DTO タイプ クラスになります。ビジネス ロジックを含める必要はありません。他のサービスが要求を処理し、応答を提供するために必要な情報だけを含める必要があります。

いくつかのプラグインの非常に単純化されたバージョンをモックアップしましたが、他のプラグインとの相互作用の解決策は次のようになります: http://screencast.com/t/Mdb9wUmMF

この図では、Navigation、Page、Search、およびその他のプラグインは相互に何も認識していません。しかし、彼らは利用可能なメッセージと ProcessMessages インターフェイスについて知っています。

例: リクエスト/レスポンス メッセージ

Navigation およびその他のプラグインは、GetPagesRequest を ProcessMessages に送信すると、必要なすべての情報を含む PagesResponse が返されることを認識します。(Nav/Other プラグインは GetPagesRequest への応答をすぐに必要とします。)

Navigation およびその他のプラグインは、Page プラグインについて何も知りません。

リクエスト/レスポンス メッセージの要件

リクエスト メッセージを生成するプラグインは、常に (通常は?) すぐにレスポンス メッセージを期待します。

リクエスト メッセージの処理方法を知っているサービスは 1 つだけであり、呼び出し元のプラグインに返されるレスポンス メッセージを提供します。

例: イベント メッセージ

ユーザーがページ プラグインでページの URL を更新すると、プラグインは PageUrlUpdated メッセージを ProcessMessages に送信します。その後、Navigation and Other プラグインは PageUrlUpdated メッセージを消費し、必要なことは何でも行います。

イベント メッセージの要件

イベントを発生させるプラグインは、応答を期待しません。0-多くのプラグインが特定のメッセージを消費する可能性があります。

(テクニカル ノート: イベント メッセージの場合は、MassTransit と RabbitMQ に送信します。メッセージごとに 1 ～ n 個のコンシューマーがあります)

質問

  1. 私たちが作成したいくつかのスケッチから、上記のアイデアは機能しているように見え、システムのさまざまな要素間の相互依存性が大幅に少なくなっています。しかし、デザイン パターンやアーキテクチャ構造の名前がわかりません。あるいは、間違った方向に進んでいるかどうかもわかりません。誰かが私に適切な解決策を教えてくれることを望んでいました-いくつかの優れたドキュメントと例が優れているでしょう。(車輪の再発明を避けようとする - 既存のパターンはより堅牢で成功する可能性が高い)

  2. リクエスト メッセージについては、リクエスト メッセージから、メッセージを処理する具体的なプラグイン / サービスへのある種の StructureMap 風のマッピングを想定していました。繰り返しますが、これは以前に解決されており、そのためのパターンがあると確信しています。または、完全に間違った方向に進んでおり、より良い解決策があります。

どんな助けやアイデアも大歓迎です

PS - いくつかの基本的なプロパティを持つ共通のプロジェクトに IWidget も用意します。そのため、Pages プラグインは、IWidget を実装するすべてのクラスを要求してページに追加することができます。

4

1 に答える 1

4

あなたの質問は、さまざまなアプローチの対象となります。しかし、私はサービス指向アーキテクチャを提案するかもしれません。主に、非常に迅速かつ機敏な方法でビジネスに適応できるためです。このアーキテクチャには多くの利点があります。

  • 軽量
  • アジャイル
  • コードの再利用性

ただし、次のような克服しなければならない一連のハードルがあります。

  • 相互運用性
  • 安全
  • パフォーマンス
  • 持続性

したがって、これらの解決策のいくつかを実装すると、このような問題が軽減される場合があります。ただし、そのためには、その問題についてのある程度の知識が必要になります。このアーキテクチャはアジャイルですが、すべてがある程度公開されています。さらに、インスタンス化されている複数のインスタンスについてはどうですか?

これらはすべて、識別しなければならない可能性のある項目です。

私が個人的にやりたいことは、プロジェクトではなく、ビジネスの真のコアを見つけることです。しかし、ビジネス。次に、そのタスクを達成するのに最適なアプローチを決定します。それは、ビジネスのコアがその中心にあるため、持続するモデルになります。

この件に関して私が強くお勧めするのは次のとおりです。

他にも実用的な本はたくさんありますが、それらは私が非常に役立つと思ったものです。彼らは、以下を含む膨大な数の設計議論を結集します。

  • 遅延読み込み
  • 作業単位
  • リポジトリ
  • 依存性注入
  • モデル拡張フレームワーク
  • もっと...

これにより、いくつかのギャップが埋められます。しかし、私は十分に強調することはできません。どのテクノロジーも互いに優れているわけではなく、すべてに長所と短所があります。しかし、ビジネス目標を最もよく捉えるテクノロジーこそが理想的な選択です。

また、お役に立てる回答が必要であることは理解していますが、次のことを覚えておいてください。

         Ask not the Elves for counsel, as they both say yes and no.

私たちがあなたのプロジェクトやビジネスを知らないという理由だけで、それらの目標はあなたの決定に大きな影響を与えるでしょう. それらはあなただけが知っていることです。私が述べたように、あなたが説明したいことを私たちは知りません：

  • 会社の目的
  • 保守性
  • 企業の成長予測
  • 会社のパラダイムのシフトの可能性。

他にもありますが、アプリケーションの減衰率がしばらく停滞したままになるには、これらの変数のいくつかを考慮する必要があります。そのため、アプリケーションの寿命はかなり長く続きます。

それが役に立てば幸いですが、それは私の2セントです。

于 2013-03-11T23:21:37.120 に答える