12

私は全国の会社で働いているので、私たちが開発するソフトウェアは大規模です。

私たちのコアシステムは、を含むWebベースwebservicesです。現在、プロジェクト全体を再設計しており、プロジェクト構造を開始する瞬間です。

とに基づくWebプロジェクトを含む7つのWebモジュールがStruts2ありSpring 3.1ます。およびに基づくWebserviceコアJAX-WSSpring 3.1

私の質問は、次のようなプロジェクトのプロジェクト構造とモジュール化を設計するためのベストプラクティスは何ですか。

私たちは間違いなく使用MavenしOSGi、必要に応じて使用します。私は次のようなことを考えています

WebProject.war
   |---Web.xml
   |--- Libs
   |
   |--- Web Module1.jar
   |--- Web Module2.jar
   |--- Web Module3.jar
   |--- Web Module4.jar
   |--- Web Module5.jar
   |--- Web Module6.jar

 WebService.war
   |---Web.xml
   |--- Libs
   |
   |--- Service.jar
   |--- Service2.jar

 EJBProject.jar
   |
   |--- module.jar
   |--- module2.jar

WebModule1.jarこれは私が個人的に念頭に置いていることですが、他のモジュールやメインプロジェクトに影響を与えることなく作業および展開できるように、よりモジュール化されたものを探していますWebProject.war。また、これを使用して、専門チームにプロジェクトのコードのみを持たせたいので、チームでのみ作業する必要がある場合はService2.jar、他のプロジェクトIDEのコードService2.jarとリソースプロジェクトのみがコンパイル済みになります。

ありがとう

4

5 に答える 5

9

モジュール性の重要な側面は、モジュールが人間的に可能な限りほとんど知らないため、さまざまなコンテキストで再利用できることです。バグは仮定に違反した場合にのみ発生します。仮定を最小限に抑えることが最大のバグキラーです。OSGiは、仮定をローカルに保つのに非常に優れたµservicesのようなツールを提供します。

レイアウトはWebプロジェクトに非常によく似ていますが、自分で開発する必要のあるほとんどのコードは、それを提示するために使用されるテクノロジーから独立している必要があるため、これは間違っています。Webアプリケーションがブラウザに急速に移行し、ブラウザが再びファットクライアントになりつつあるため、このテクノロジーはすべて近い将来変更される可能性があります。つまり、純粋なメッセージングが何をしているのかを見ると、非常に最新のRESTインターフェースはすでに非常に古風な感じがします。このすべての変動性は、モジュールを可能な限り分離させたいことを意味します。

したがって、ドメインコードを、Webテクノロジに結合されているライブラリに結合されているものに結合することは決してありません。これらの推移的な依存関係は、（近い）将来あなたを傷つけるでしょう。小さなまとまりのある非結合モジュールを構築し、それらをレゴブロックとして使用してアプリケーションを構築します。

于 2012-04-20T07:37:49.297 に答える
6

Kirk Knoernschildの「Javaアプリケーションアーキテクチャ：OSGiを使用した例を使用したモジュール性パターン」を読むことを強くお勧めします。OSGiに移行する前に、アプリをモジュール化することから始めることができます（まだ持っていない場合は、確実に優れたテストカバレッジに投資します）。

サーブレット仕様3.0を使用している場合は、Webフラグメントの使用を検討してください。

あなたが示した構造に関しては、何もネストしないでください（Webフラグメントを除く）。WARはWAB（Webアプリケーションバンドル-基本的には細いWAR）になる可能性があります。また、OSGiのμServicesを可能な限り活用します-それが楽しみの始まりです=）

KarafやVirgoのようなエンタープライズOSGiフレームワークは、JEE-OSGiの分割にまたがっている間、多くのサポートを提供します（EquinoxとFelixだけでは、必要最低限​​のものです）。

于 2012-04-19T10:05:33.603 に答える
1

独立したモジュールの開発や実行時の更新などのプロジェクト要件に基づいて、Mavenが最適なソリューションです。依存関係とプラグインの優れたサポートを提供し、プロジェクトに必要なすべてのものがすでに利用可能になっているように見えます。

  • Spring / Struts / CXF/etc。Mavenアーティファクト、
  • WAR /JAR/など。プラグイン、
  • アプリケーションサーバーはプラグインなどをデプロイ/テストします。
  • また、すべてのコードベースを共有せずに特定のモジュールのみを開発するチームに、一般的なMavenアーティファクトのみを提供できます。
  • Mavenは、すべての継続的インテグレーションサーバー（Hudson / TeamCityなど）でサポートされています。

OSGi。それを使用したい場合は、現在の設計を注意深く調べて、μServicesに適合させる必要があります。一般に、API、APIコンシューマー、APIプロバイダーを備えたモジュールがあります。チーム間で開発を分割するのに役立ちます（たとえば、1つはAPIコンシューマーモジュールを開発し、もう1つはAPIプロバイダーモジュールを開発します）。必要に応じて、APIコンシューマー/プロバイダーモジュールを2つ以上のOSGiバンドル（Mavenモジュール）に分割できます。

于 2012-04-19T14:15:32.233 に答える
0

あなたの構造は私にはよく見えますが、これはほとんどのプロジェクトの典型的な構造です-私が与える1つの推奨事項は、依存関係をバージョン管理することです。たとえば、webproject.warをwebmodule1-1.3に依存させると、このように潜在的に異なる終わりになりますプロジェクトには、依存するjarのバージョンが異なる場合があります。

Mavenを使用すると、これらの依存関係の管理が確実に簡素化されます

要件が実行時に依存関係を置き換えることである場合は、はい、OSGIのようなテクノロジーを選択する必要がありますが、探しているのが実行時のモジュール化でない場合は、OSGiから始めず、スタックを単純に保つことをお勧めします。

于 2012-04-19T12:53:03.703 に答える
-2

OSGiを少し扱い、少し苦労した後、Spring用のosgiなしのモジュール性を開発しましたhttps://github.com/griddynamics/banshunよろしくお願いします！

于 2013-08-30T21:33:56.260 に答える