2016-10-01 6 views
1

既存のJavaプロジェクトをmavenプロジェクトに変換しようとしています。私は以下のアプローチを念頭に置いていますが、私が正しい方向に向かっているかどうかはわかりません。Spring Java Mavenプロジェクト+モジュールデザイン

第1のアプローチは、すべてのエンティティ、リポジトリ、サービス、定数、実装クラスを1つの単一のMavenモジュール/プロジェクトにグループ化することです。

第2のアプローチは、すべてのサービスクラスをそれぞれのMavenモジュール/プロジェクトに、エンティティの残りをリポジトリクラスとしてベースモジュールにすることです。

私はどのアプローチをとるべきですか?

アプローチ1

finance-module 
- com.example.finance.entities 
- com.example.finance.repository 
- com.example.finance.service 

order-module 
- com.example.order.entities 
- com.example.order.repository 
- com.example.order.service 

code-module 
- com.example.code.entities 
- com.example.code.repository 
- com.example.code.service 

アプローチ2

finance-module 
- com.example.finance.service 

order-module 
- com.example.order.service 

code-module 
- com.example.code.service 

base-module 
- com.example.finance.entities 
- com.example.finance.repository 
- com.example.order.entities 
- com.example.order.repository 
- com.example.code.entities 
- com.example.code.repository 
+2

アプローチ1あなたのモジュールは疎結合されます – fmodos

答えて

1

あなたが持っている最初のアプローチを使用して、タイプ別のフォルダの種類を(持っている第二のアプローチ対機能によってフォルダを有する古典的なケースであります私はそれをそのように呼びますか?)両方のアプローチに長所と短所がありますが、個人的な選択は、モジュールを機能別に整理することです(アプローチ-1)。ここで

が理由として私の2セントです:アプリケーションのサイズが大きくなるにつれて

a)は、特定のファイルに行くことは、多くのパッケージがある問題です。要するにナビゲーション問題。

B)あなたは独立して、これらの異なるモジュールに取り組んで複数のチームを持っていると子ポンポンのを持つように設計された親のポンポンを持つことができます/解放のために構築されたモジュールがまだ維持コード別離

C)モジュールが緩く&を結合封入さクラスA→B、B→A問題のため、他のビルドを破らない可能性があります。

関連する問題