これまでは、maven-modularプロジェクトでパッケージの命名に単純な戦略を使用してきました。各パッケージ名には、パッケージが配置されているモジュールの名前が含まれています。たとえば、単純なプロジェクトは次のような構造になります。
- smweb-core(module)
-- src/main/Java { cz.sm.core(parent package) }
-- pom.xml
- smweb-web(module)
-- src/main/Java { cz.sm.web(parent package) }
-- pom.xml
- pom.xml
問題は、現在、私が長年開発してきたはるかに大きなプロジェクト(2000以上)Javaソースファイル)に取り組んでいることです。私のプロジェクトは、このプロジェクト構造をモジュール式に再構築することです。循環依存関係の作成に時々遭遇します(モジュールはほとんど排他的ですが、100%排他的にすることはできません)。モジュール間で依存関係クラスを移動することによってこれを解決します。この回避策は、内部にいくつかのクラスがあるため、パッケージの命名戦略を無効にしますまったく異なるワークスペースに属している可能性があるこれらのモジュール。
私の頭に浮かんだ最初のアイデアは、すべてのパッケージ名からモジュール名を削除することです。つまり、プロジェクト全体に対して1つのパッケージ構造が存在しますが、その内容はモジュール内で個別に分割されます。このソリューションの問題は、1つのモジュールが他のモジュールに配置されている可能性があるため、一部のパッケージのすべての機能が常に提供されるとは限らないことです。
2番目のアイデアは、最初に述べたネーミング戦略に固執することですが、別のモジュールから移動する必要がある機能ごとに、別のモジュールの名前を含む現在のモジュール内にパッケージを作成します。前述の例で、smweb-coreモジュールがsmweb-webモジュールと循環依存関係にある場合、依存関係を移動するときに次の構造を実行します。
- smweb-core(module)
-- src/main/Java
{ cz.sm.core(not longer parent package) }
{ cz.sm.web(functionality moved from web module to resolve cyclic dependency) }
-- pom.xml
- smweb-web(module)
-- src/main/Java
{ cz.sm.web(not longer parent package) }
{ cz.sm.core(functionality moved from core module to resolve cyclic dependency) }
-- pom.xml
- pom.xml
今のところ、2番目の命名戦略を使用することで問題が発生することはありません。私の質問は次のとおりです。将来の問題を防ぐために、どの命名戦略に従うべきですか。これらの命名戦略は、私が従うべき良い習慣/設計パターンにブレーキをかけますか?この問題のより良い解決策はありますか?
すべての回答をありがとうございます。
同じJavaパッケージをプロジェクト/アーティファクト間で分割することは良いアイデアではありません。署名、クラスローディング、およびその他のメカニズムと組み合わせるとうまく機能しない可能性があります。また、かなり混乱します。これは両方の提案を無効にします。私があなたを正しく理解したなら。
問題の根源は循環依存関係があることです。これはおそらく、プロジェクトに構造を持たせていないためです。多くの場合、これは機能によって構造が駆動される代わりに、技術的なパッケージングが原因です。
つまり、「web」、「core」、および同様のパッケージは存在すべきではありません。それは単なる任意のグルーピングです。パッケージ名は、クラス名やメソッド名と同様に機能を伝達する必要があります。したがって、1つのパッケージには、1つの機能に必要なすべての技術的側面が含まれている必要があります。
このようにして、「web」などの技術的な依存関係が「core」に依存するのではなく、「現金転送」が「アカウント」などに依存するなど、依存関係が「実際の」依存関係になります。
これはこの主題についての私の記事です: Happy Packaging!