Javaプロジェクトのパッケージ構造？

Java Webアプリケーションでパッケージ構造を設定するためのベストプラクティスは何ですか？

src、単体テストコードなどをどのように設定しますか？

Mavenの標準プロジェクトレイアウトに従うことができます。実際にmavenを使用する必要はありませんが、将来的には（必要に応じて）移行が容易になります。さらに、多くのオープンソースプロジェクトがこのようにレイアウトされているため、他の開発者はそのレイアウトを見ることになります。

チェックする可能性のある既存のリソースがいくつかあります。

1. Javaクラスを適切にパッケージ化する
2. Spring 2.5アーキテクチャ
3. Javaチュートリアル-パッケージの命名
4. SUNの命名規則

価値があることについて、私が使用する傾向がある私の個人的なガイドラインは次のとおりです。

1. 「com.mycompany」などの逆ドメインから始めます。
2. 「myproduct」などの製品名を使用します。場合によっては、特定の製品に属さない一般的なパッケージを使用する傾向があります。これらは、「io」、「util」、「ui」など、これらの一般的なクラスの機能に従って分類されます。
3. この後、より自由な形式になります。通常、プロジェクト、機能の領域、展開などに基づいてグループ化します。たとえば、「project1」、「project2」、「ui」、「client」などがある場合があります。

他のいくつかのポイント：

1. 私が取り組んだプロジェクトでは、パッケージ名が設計ドキュメントから流れるのはよくあることです。通常、製品はすでに機能または目的の領域に分かれています。
2. 共通の機能をすぐに上位のパッケージにプッシュすることについてあまり強調しないでください。プロジェクトや製品などで必要になるのを待ってから、リファクタリングします。
3. パッケージ間の依存関係を監視します。すべてが悪いわけではありませんが、個別のユニットである可能性のあるものの間の密結合を示している可能性があります。これを追跡するのに役立つツールがあります。

実装レイヤーではなく、機能ごとにパッケージ構造を作成することをお勧めします。これについての良い記事は、Javaプラクティスです：レイヤーではなく機能ごとのパッケージ

私は通常、次のものが欲しいです。

• bin（バイナリ）
• doc（ドキュメント）
• inf（情報）
• lib（ライブラリ）
• res（リソース）
• src（ソース）
• tst（テスト）

これらは型にはまらないと考えられるかもしれませんが、物事を整理するための非常に良い方法だと思います。

The way I usually organise is
- src
        - main
                - java
                - groovy
                - resources
        - test
                - java
                - groovy
- lib
- build
        - test 
                - reports
                - classes
- doc

私が通常フォルダの階層を持っている方法-

• プロジェクト名
  • src
  • 置き場
  • テスト
  • libs
  • docs

もう1つの方法は、API、サービス、およびエンティティを異なるパッケージに分離することです。