[解決済み】（Java）パッケージの構成に関するベストプラクティスはありますか？[クローズド]。

質問

少し前のことですが、Javaのパッケージの細かな構成についての質問がここで回答されていました。 例えば、以下のようなものです。 my.project.util , my.project.factory , my.project.service など。

今は見つからないので、質問させていただくかもしれません。

Javaにおけるパッケージの構成とその中に入るものに関して、ベストプラクティスはあるのでしょうか？

Javaプロジェクトでは、クラスをどのように整理していますか？

たとえば、私が数人でやっているプロジェクトには、beanというパッケージがあります。最初は単純なビーンズを含むプロジェクトだったのですが、（経験不足と時間不足で）すべてを（ほとんど）含んでしまうことになりました。 いくつかのファクトリークラスをファクトリーパッケージ（ビーンを作成する静的メソッドを持つクラス）に入れることで、それらを少し整理しましたが、ビジネスロジックを行う他のクラスや、プロパティファイルからコードに対するメッセージを取得するような（ビジネスロジックではない）簡単な処理を行うクラスもあります。

皆様のご意見、ご感想をお待ちしております。

解決方法は？

パッケージの構成やパッケージの構造化については、通常、激しい議論が交わされます。以下はパッケージの命名と構造化に関する簡単なガイドラインです。

• javaに従う パッケージの命名規則
• ビジネス上の役割だけでなく、機能的な役割に応じてパッケージを構成する
  • 機能またはモジュールに従ってパッケージを分解する。 com.company.product.modulea
  • さらに、ソフトウェアのレイヤーに基づいた分割も可能です。しかし、もしパッケージの中にいくつかのクラスしかないのであれば、パッケージの中にすべてを入れることは理にかなっています。 com.company.product.module.web または com.company.product.module.util などです。
  • IMOは、緊急の必要性がない限り、例外やファクトリーなどを個別にパッケージングすることは避け、構造化で行き過ぎないようにします。
• プロジェクトが小さい場合は、パッケージの数を少なくしてシンプルにしましょう。 com.company.product.model と com.company.product.util など。
• で人気のあるオープンソースプロジェクトのいくつかを見てみましょう。 Apacheプロジェクト . 様々な規模のプロジェクトで、どのように構造化を使用しているかを見てみましょう。
• また、名前を付ける際にビルドと配布を考慮します（APIやSDKを別のパッケージで配布することができます、サーブレットAPIを参照してください）。

何度か実験と試行を繰り返せば、自分が納得できる構造を思いつくことができるはずです。一つの慣習に固執せず、変化を受け入れることが大切です。