私が現在関わっているプロジェクトでは、約 60 個のポートレットの開発が必要です。ポートレット WAR には任意の数を含めることができることを認識しているため、WAR に含めるべきポートレットの数がわかりません。
極端な状況は、WAR によってポートレットが 1 つしかない場合です。このアプローチにより、ポートレットの独立性が得られますが、デプロイメント アーティファクトの数を管理するのは非常に困難です。一方、60 個のポートレットに対して 1 つまたは 2 つの WARS しかない場合、デプロイ アーティファクトは 2 つだけになりますが、1 つのポートレットに小さな変更を加えただけでも、それらの多くを再デプロイする必要があります。
そのためのベストプラクティスや推奨事項はありますか?
効率化のために、WAR ごとに多数のポートレットをバンドルする必要があります。本当に重要なのは EAR の数ですが、WAR ごとに個別の EAR を構築していると仮定しています。したがって、元のステートメントはまだ有効です。
ご指摘のとおり、60 個すべてを 1 つの WAR にバンドルするのは極端であり、展開と再テストの要件に関して他の問題が発生します。ポートレットを論理的に類似した機能のグループにパッケージ化することをお勧めします。たとえば、連携して単一の機能を提供するポートレットは、変更される傾向があり、いずれにしても一緒に再デプロイする必要があるため、一緒にパッケージ化する必要があります。確かに、WAR ごとに 10 個のポートレットは管理可能であり、アプリを 6 つの EAR に分割することも非常に管理しやすい数です。各 EAR には一定のオーバーヘッドがあることを覚えておいてください。開発ライフサイクルについて考えてみると、EAR が多すぎると、開発サーバーの再起動時間がとんでもないものになり始めます。大きな EAR は、小さな EAR よりも開始にそれほど時間がかかりません。これは、展開時間にも当てはまります。
ビルド/デプロイの柔軟性 (多くの EAR) と、ランタイム メモリの使用、デプロイ、および再起動時間 (少ない EAR) の間の満足のいく中間点に到達することがすべてです。