私はしばらく前にこれについて考えましたが、私の店が最初の実際のJava Webアプリを実行しているときに最近再浮上しました。
イントロとして、2つの主要なパッケージ命名戦略を見ます。（明確にするために、この「domain.company.project」の部分全体を指すのではなく、その下のパッケージ規則について話しています。）とにかく、私が見るパッケージの命名規則は次のとおりです。
機能：パッケージを、ビジネスドメインに基づくIDではなく、機能に応じてアーキテクチャに名前を付けます。 これの別の用語は、「レイヤー」に基づく名前付けかもしれません。したがって、*。uiパッケージ、*。domainパッケージ、および* .ormパッケージがあります。パッケージは垂直ではなく水平スライスです。
これは論理的な命名よりもはるかに一般的です。実際、これを行うプロジェクトを見たことも聞いたこともないと思います。もちろん、私はひどく頭がよくないので（NPの問題の解決策を思いついたようなものです）、誰もが自分のやり方でやるには大きな理由があるはずだと思います。一方、私はちょうど部屋に象を行方不明の人に反対していないよと、私は実際の引数聞いたことがないため、このように名前を付けるパッケージをやって。それは事実上の標準のようです。
論理：パッケージをビジネスドメインIDに従って名前を付け、その垂直方向の機能スライスに関係するすべてのクラスをそのパッケージに入れます。
前に述べたように、これについては見たり聞いたりしたことがありませんが、それは私にとっては意味のあることです。
私はシステムを水平ではなく垂直にアプローチする傾向があります。データアクセス層ではなく、注文処理システムを開発したいと考えています。明らかに、そのシステムの開発でデータアクセス層に触れる可能性は十分ありますが、重要なのは、そのように考えていないということです。これが意味することは、もちろん、変更要求を受け取ったり、いくつかの新しい機能を実装したりするときに、関連するすべてのクラスを見つけるために、たくさんのパッケージを探し回る必要がないのは素晴らしいことです。代わりに、私がしていることはXと関係があるため、Xパッケージを調べるだけです。
開発の観点から、私はあなたのパッケージがあなたのアーキテクチャーではなくあなたのビジネスドメインを文書化することは大きな勝利だと思います。ドメインはほとんど常にシステムの一部であり、システムのアーキテクチャが、特にこの時点で、実装においてほぼ平凡になっているため、理解するのが難しいように感じます。このタイプの命名規則を使用してシステムにアクセスでき、パッケージの命名から即座にシステムが注文、顧客、企業、製品などを扱うことができるという事実は、かなり便利なようです。
これにより、Javaのアクセス修飾子をより効果的に利用できるようになります。これにより、システムのレイヤーではなくサブシステムへのインターフェースをより明確に定義できます。したがって、透過的に永続化したい注文サブシステムがある場合、理論的には、DAOレイヤーに永続クラスへのパブリックインターフェイスを作成せずに、DAOクラスをそれが扱うクラスだけで。もちろん、場合あなたは、この機能を公開したかった、あなたはそれのためのインタフェースを提供したり、それを公開することができます。システム機能の垂直スライスを複数のパッケージに分割することで、これの多くを失うようです。
私が見ることができる1つの不利な点は、それがレイヤーの切り取りを少し難しくすることだと思います。パッケージを削除または名前変更してから、別のテクノロジーを使用して新しいパッケージを所定の場所にドロップする代わりに、すべてのパッケージ内のすべてのクラスを変更する必要があります。しかし、これは大した問題ではないと思います。経験不足のせいかもしれませんが、テクノロジーを入れ替える回数は、システム内で垂直方向の機能スライスにアクセスして編集する回数と比較すると、見劣りするものだと想像しなければなりません。
だから私は質問があなたに出てくると思います、あなたはあなたのパッケージにどのように名前を付けますか、そしてなぜですか？私は必ずしもここで金色のガチョウや何かに偶然出会ったとは限らないことを理解してください。私はこれらすべてにかなり新しいですが、ほとんどが学問的な経験があります。しかし、私は私の推論の穴を見つけることができないので、私が先に進むことができるように、皆さんができることを望んでいます。