問題タブ [modularity]

現在のアプリは単一の JVM で実行されます。

現在、アプリを個別の論理サービスに分割しており、各サービスは独自の JVM で実行されます。

分割は、システム全体に影響を与えることなく、単一のサービスを変更して展開できるようにするために行われています。これにより、システム全体の QA の必要性が減ります。必要なのは、変更されるサービスとの相互作用の QA だけです。

サービス間通信には、REST、MQ システム バス、およびデータベース ビューを組み合わせて使用​​します。

これについて私が気に入らない点:

• REST は、XML との間でデータをマーシャリングする必要があることを意味します
• DBビューはシステムを結合し、個別のサービスの概念全体を無効にします
• MQ / システム バスが複雑になる
• サービス間で必然的にコードの重複が発生する
• n 個の JBoss サーバー構成をセットアップしました。n 個のデプロイ、n 個のセットアップ スクリプトなどを実行する必要があります。

アプリを単一の JVM で実行できるようにしながら (そして関連する利点を実現しながら)、モジュール式の開発と展開を可能にする内部アプリケーションを構築するためのより良い方法はありますか?

Prism を学習していますが、メイン シェルの最適なアプローチについて質問があります。

シェルにツールバーとメインの 2 つの領域があると仮定します。ツールバーには、それぞれが異なるオンデマンド ロード モジュールを表す 3 つのメイン ボタンがあります。これらの各モジュールは現在、メイン リージョンに適合するものとして登録されています。

ボタンの1つをクリックすると、次のことをしたい：

保留中のアクションがまだ必要な場合にキャンセルするオプションを使用して、アクティブなビューにその切り替えを通知します。これは、子ビューにカスケードする場合があります。

アクションがキャンセルされていない場合、まだロードされていない場合はオンデマンド モジュールをロードし、そうでない場合はリージョン内でアクティブ化します。

これら 3 つのモジュールはすべて同じリージョンに収まる必要がありますか、それともシェルでコンテンツ プレゼンター内に 3 つのリージョンを定義する必要がありますか?

私が行き詰まった領域の 1 つは、モジュールの初期化からビューを登録するときに、厳密に型指定された名前で追加されないことでした。 viewname) は常に null を返すため、リージョンに別のビューを追加することになります。

私は大きなジレンマに陥っています..私はASP.NET MVC 2で高度にモジュール化されたWebアプリに取り組んでいます(実際、コアは超軽量になり、すべてモジュール/プラグインで動作します)。MEF はモジュールの検出に非常に役立つことがわかりましたが、IoC コンテナーとして使用したくありません。「真の」IoC コンテナーの高度な機能が必要になる可能性は十分にあるので、Unity を使用したいと考えています。

そしてここに問題があります:モジュールがコンテナを(プログラム的に)構成できるようにする方法=すべてのモジュールでUnityに強く依存することなく、アプリケーションの開始時に独自のタイプ(mvcコントローラー、サービスのカスタム実装...)を登録しますか? 私はCommon Service Locatorプロジェクトについて知っていますが、それはかなり良いようですが、このインターフェース共同コンテナは型の解決のみを許可し、それらを登録することはできません(afaik)。

あなたが私の言いたいことを理解してくれることを本当に願っています.

大規模な進化するマルチモジュール Maven プロジェクトを開発している場合、pom に不要な依存関係がいくつかあることは避けられないようです。それらは他の依存関係によって推移的に含まれているためです。たとえば、元々 C を含むモジュール A がある場合に、これが発生します。後でリファクタリングし、A をモジュール B に依存させ、モジュール B が C に依存するようにします。十分に注意しないと、B と C の両方が含まれてしまうことになります。 A の依存リスト。しかしもちろん、C を A の pom に入れる必要はありません。とにかく、C は推移的に含まれているからです。そのような不要な依存関係を見つけるツールはありますか?

（これらの依存関係は実際には害はありませんが、実際のモジュール構造がわかりにくくなる可能性があり、通常は pom に含まれるものが少ない方が良いです。:-)

私たちのチームは、サイズがはるかに大きいプロジェクトに移行しており、その多くは、その中でいくつかのオープンソースプロジェクトを使用しています。

ライブラリと依存関係を比較的モジュール化して、新しいリリースがリリースされたときに簡単にアップグレードできるようにするためのアドバイスやベストプラクティスはありますか？

言い換えれば、オープンソースプロジェクトのフォークであるプログラムを作成するとします。両方のプロジェクトが成長するにつれて、コアの更新を維持および共有するための最も簡単な方法は何ですか？

私が求めていることについてのアドバイスをお願いします...「代わりにこれを行うべきです」または「なぜあなたは」という必要はありません。ありがとう。

Zend Frameworkのモジュール間の依存関係をどのように処理して、再利用可能なドロップインモジュールを作成しますか？

たとえば、ユーザーが電子メールアドレスを提供して購読できるニュースレターモジュールがあります。

次に、電子メールで投稿を購読できるブログモジュールを追加する予定です（ニュースレターの一部の機能は明らかに重複していますが、電子メールアドレスはユーザーモデルに保存されています）。次はフォーラムモジュールで、同じサブスクライブで投稿機能を備えています。

しかし、私はこれらのモジュールをそれぞれに依存せずに使用できるようにしたいと考えています。つまり、ニュースレターのみのアプリケーション、ブログ付きのニュースレター、2つまたは3つのモジュールの組み合わせです。

これはかなり一般的です。たとえば、検索機能を使用した同じストーリーです。すべてのデータ、ブログデータ、またはフォーラムデータ（利用可能な場合）を検索するオプションを備えた検索モジュールが必要です。

このためのデザインパターンはありますか？
モジュールごとに同様の、いくつかの追加moduleExists($moduleMame)、またはいくつかのインターフェイスまたは抽象クラス、いくつかの基本コントローラーパターンを提供する必要がありますか？

C ++ / Luaゲームコードを整理する方法を分類し、それらの義務を分離するのを手伝ってください。最も便利な方法は何ですか、どれを使用しますか？

たとえば、Luaは、C ++オブジェクトの初期化のみ、またはゲームループの反復ごとに使用できます。ゲームロジックのみ、またはグラフィックスにも使用できます。一部のゲームエンジンは、スクリプトからすべてのサブシステムを完全に制御します。私はこのアプローチが本当に好きではありません（分離はまったくありません）。

すべてのゲームオブジェクト（npc、場所）をC ++オブジェクトなしのLuaテーブルとして実装するのは良い考えですか？または、それらをミラーリングする方が良いですか（C ++オブジェクトを制御するためのLuaテーブル）？または、他の何か？

ありがとうございました。

編集。私の分類：LuaとC ++：職務の分離。

トピックの続き：Lua、ゲームの状態、ゲームのループ

これは大きな問題です。

私は、基本的なモジュラーアーキテクチャを備えた、適切に構造化されたモノリシックコードベースを持っています（すべてのモジュールはインターフェイスを実装しますが、同じクラスパスを共有します）。このアプローチの愚かさと、ライブラリのバージョンが競合している可能性のあるアプリケーションサーバーにデプロイするときに発生する問題を認識しています。

私は現在約30個の瓶に依存しており、それらを束ねていますが途中です。これで、ネットワークコンポーネントなど、一部のモジュールはバージョン管理された依存関係を簡単に宣言できます。これらは、JREおよびその他のBNDdedライブラリ内のクラスを静的に参照しますが、JVM関連のコンポーネントはClass.forName（...）を介してインスタンス化され、任意の数のドライバーの1つを使用できます。

私はすべてをサービスエリアごとにOSGiバンドルに分割しています。

• 私のコアクラス/インターフェース。
• 関連するコンポーネントのレポート。
• データベースアクセス関連コンポーネント（JDBC経由）。
• 等....

私のコードが、すべての依存関係を持つ単一のjarファイルを介してOSGiなしで、OSGiなしで（JARJARを介して）引き続き使用できるようにし、OSGiメタデータと依存関係情報を含む詳細なバンドルを介してモジュール化できるようにしたいと思います。

• クラスパス上および/またはOSGiコンテナー環境（Felix / Equinoxなど）内で任意のドライバーを動的に利用できるように、バンドルとコードを構成するにはどうすればよいですか？

• コンテナー間で互換性のあるOSGiコンテナー（Felix / Equinoxなど）で実行されているかどうかを検出する実行時の方法はありますか？

• OSGiコンテナーにいる場合、別のクラス・ロード・メカニズムを使用する必要がありますか？

• データベースモジュールを介してバンドル時に不明なJDBCドライバーをロードできるようにするには、OSGiクラスをプロジェクトにインポートする必要がありますか？

• ドライバーを取得する2番目の方法もあります（JNDIを介して、アプリサーバーで実行している場合にのみ実際に適用できます）。OSGi対応アプリサーバーのJNDIアクセスコードを変更する必要がありますか？

いくつかの着信（SOAP）Webサービス、いくつかの発信Webサービス、それらと内部フォーマット間の変換、内部ロギングサービス、外部アーカイブWebサービスへのアクセス、遅延などを含む大規模なアプリケーションをどのようにモジュール化しますか？

1つの方法は、機能をWARのコレクションに分割し、それらすべてを1つのアプリケーションサーバーにデプロイして、内部Webサービスと通信させることです。これには、特にメッセージが大きい場合にオーバーヘッドが発生し、スレッド数の制限などによりパフォーマンスの問題が発生する可能性があります。

もう1つの方法は、すべてを巨大なWARに入れて、直接通信できるようにすることです。正確にはモジュール化ではありません。あなたならどうしますか？

私が取り組んでいるサイトは、ユーザー ベースと機能の両方の面で成長しており、一部の管理タスクをパブリック Web サイトから分離する必要があることが明らかになりつつあります。これを行う最善の方法は何だろうと考えていました。

たとえば、このサイトには大規模なソーシャル コンポーネントと、公開販売インターフェイスがあります。しかし同時に、バック オフィス タスク、一括アップロード処理、ダッシュボード (実行時間の長いクエリを含む)、および管理セクションにある顧客関係ツールは、パブリック トラフィックのスパイクの影響を受けないようにしたい (またはパブリック トラフィックに影響を与えたくない)。直面している応答時間)。

このサイトはかなり標準的な Rails/MySQL/Linux スタックで実行されていますが、これは実装の問題というよりもアーキテクチャの問題だと思います。主に、これらの異なるアプリケーション間でデータとビジネス ロジックをどのように同期させるのでしょうか?

私が評価しているいくつかの戦略：

1)公開データベースのスレーブ データベースを別のマシンに作成します。 アプリケーション間で共有できるように、すべてのモデルとライブラリ コードを抽出します。管理インターフェイス用の新しいコントローラーとビューを作成します。

私はレプリケーションの経験が限られており、この方法で使用されることになっているのかどうかさえわかりません (ほとんどの場合、同じアプリケーションの読み取り機能をスケールアウトするためであり、複数の異なる機能を持つのではありません)。 . スレーブが同じネットワーク上にない場合、レイテンシの問題が発生する可能性についても心配しています。

2)新しいよりタスク/部門固有のアプリケーションを作成し、メッセージ指向のミドルウェアを使用してそれらを統合します。 しばらく前に Enterprise Integration Patterns を読みましたが、分散システムに対してこれを推奨しているようでした。(あるいは、基本的な Rails スタイルの RESTful API 機能で十分な場合もあります。) しかし、データ同期の問題と、これに伴う大規模な再設計について悪夢に悩まされています。

3) 2 つの混合物。 たとえば、一部のバック オフィス タスクに必要な唯一の公開情報は、読み取り専用の完了時間またはステータスです。それを完全に別のシステムに置き、データを公開することは理にかなっていますか? 一方、ユーザー/グループ管理機能は、データベースを共有する別のシステムで実行されますか? 欠点は、これは、最初の 2 つ、特に再構築に関して私が抱いている懸念の多くを維持しているように見えることです。

答えはサイトの特定のニーズに大きく依存すると確信していますが、成功 (または失敗) の話を聞きたいです。