ドメイン、インターフェース、インフラストラクチャ、アプリケーションなどのさまざまなアーキテクチャ層を使用して小さなアプリケーションを構築しています。これは、Onion DDD モデルに従います。アプリケーションをマルチモジュールのMavenプロジェクトに分割することに利点があるかどうか疑問に思っています。私が今見る限り、それは物事を必要以上に難しくしているようです. アプリケーション全体が単一の WAR ファイルとして Tomcat コンテナーにデプロイされます。
5 に答える
アプリケーションを分割することは、次の場合に意味があります。
プロジェクトの特定の部分に新しい機能やバグ修正が必要な場合は、単にそのモジュールに集中して、そのモジュールのテストだけを実行できます。すべてのコードの一部をコンパイルし、関連するテストのみを実行すると、作業が高速化されます。
モジュールのコードは、さまざまなプロジェクトで再利用できます。あなたのプロジェクトには、メール送信用によく書かれた一般的なコードが含まれていると仮定しましょう。後でメール送信機能が必要な別のプロジェクトがある場合は、既存のモジュールを再利用するか、その上に構築することができます (依存関係として追加することにより、別のモジュールで)。
長期的にはより簡単な保守性。たぶん、今では小さなプロジェクトのように思えます。数か月後には状況が変わっている可能性があり、その場合はさらにリファクタリングを行って論理ユニット (モジュール) に分割する必要があります。
概念の明快さ (Adriaan Koster によって追加)。
WAR に関して: すべての関連モジュールから最終的な WAR ファイルをまとめて生成するアセンブリ モジュールを使用できます。
最初は、これはより多くの作業のように見えるかもしれませんが、長期的には、モジュール化されたプロジェクトの方が作業と保守が簡単です。ほとんどの正気な開発者は、このアプローチを好みます。
複数のモジュールを使用すると、依存関係の階層が必要になります。スタンドアロンで、他のモジュールに依存しないモジュールが 1 つあります。それにのみ依存する別のものがあります。何かを他のものに依存させるよりも難しいように見えるかもしれませんが、このアプローチは後で修正するのが難しい依存関係の混乱をもたらします.
階層化されたモデルに従おうとしている場合は、各レイヤーを別のモジュールに配置することをお勧めします。これにより、モデルを壊したくなることはありません。
簡単な答え: 今日は小さいですが、明日は大きくなり、保守、再利用、拡張、他のシステムとの統合などがより複雑になります。
私の知る限り、Maven は WAR の依存関係に対してほとんど役に立ちません。単一のWARについて話しているので、これは決して問題にはなりません。
Java クラスをいくつかの「jar」サブモジュールに分割することはできますが、WAR プロジェクトをいくつかの小さな WAR に分割すると、ある種の「オーバーラップ」パッケージを使用すると、複雑になります。
私たちのプロジェクトの 1 つである情報だけで、Web ページが多すぎるため、いくつかの WAR サブモジュールに分割することにしましたが、デプロイされた異なる WAR 間でセッションが共有されず、Kerberos を使用する予定はありません。最後に、Glassfish、Jetty、MyFaces などの多くのソースを変更しました。JAR 内の web.xml を解決できるようにします。プロジェクト全体を Facelets 2.0 に変換しました (JDK tools.jar とカスタム リソース ハンドラーの依存関係を回避するため)。唯一の理由は、WAR サブモジュールを JAR サブモジュールに変更し、すべての webapp/ページをクラス リソースに移動することです。結論として、Maven は JAR の依存関係に対して優れた仕事をしますが、WAR や単一の WAR はありません。
編集applicationContext.xmlベースサブモジュールの1つを入れて、それをインポートすることができclasspath:com/example/applicationContext.xmlます。また、Spring 3.0 には注釈のサポートがあり、xml ですべてを宣言する代わりに、Spring 自動スキャンを行うことができます。
プロジェクトを複数のMavenプロジェクトに分割すると、クラスを別のプロジェクトで再利用する場合や、プロジェクトが異なる構成でデプロイされる場合に役立ちます。
Webサービスについて考えてみてください。サーバーをホストしている場合は、サーバーとクライアントで使用できるドメインクラス(モデル)とエンドポイントインターフェイスのプロジェクトを構築できます。サーバーは、WARに構築された別のプロジェクトになります。
さらにクライアントを開発するために、最初のプロジェクトも使用できます。
親プロジェクトを使用して、一般的なプロジェクト(ロギングなど)およびさまざまなプロファイルとビルド構成の依存関係を管理します。