Spring Boot REST Javaマイクロサービス：なぜMavenサブモジュールを使用するのですか？

Question

Mavenサブモジュールを使用するプロジェクトを見ました。プロジェクト自体は、マイクロサービスのRestful APIエンドポイントを公開するスプリングブートアプリケーションです。例：カスタマーサービス（getCustomers、createCustomersなど）。標準モデルクラス、リポジトリ、サービスインターフェイスと実装、コントローラーなどで構成されます。

モデルクラス、リポジトリ、サービスインターフェイスと実装、コントローラー、サブモジュールを作成する理由はありますか？

明確にするために、私はこれらを比較しています：

1）通常の場合：

Project
            src
               main
                   Java
                      dao
                      model
                      service
                      controller
                   resources
               test
                   ...
             pom.xml

2）サブモジュールのケース：

Project
        dao
            src
               main
                   Java
                      dao
                   resources
               test
                   ...
            pom.xml
         service
            src
               main
                   Java
                      service
                   resources
               test
                   ...
            pom.xml

なぜ2のために行きますか？

私にとって、この構造は、各サブモジュールフォルダー内の各pom.xmlで非常に複雑に見えます。

Answer 1

私の経験では、小さなアプリや非常に小さなサービスに適しています。Mavenモジュールは、技術的および認知的な2つの方法で不必要に複雑なものにします。

ただし、モジュールは次の場合に非常に役立ちます。

• サービスは複雑であり、開発者が適切な場所で機能をすばやく見つけたり追加したりできるように、最も関連する境界を視覚化する方法が必要です。

• サービスの分解。マイクロサービスでさえ、いくつかの小さいサービスで構成できます。 Mavenモジュールを使用すると、コンポーネントの相互作用およびそれらを分離する最良の方法に関する貴重なフィードバックを得ることができます。または、彼らがいる場所を去る理由。この方法を使用すると、コードをスタンドアロンプ​​ロセスに移動するのが簡単になります。

適切にモジュール化されたアプリケーションは、懸念事項の健全な分離を強制し、アプリケーションの要素間の結合を減らすことができます。

モジュールは、戦略的な質問に対する戦術的な答えになることもあれば、必要になることもあります。例えば：

• 機能を個別に開発、進化、維持する必要があります。つまり、異なる開発ライフサイクルを提供します。
• コードまたはロジックのバージョン管理
• コードの再利用（共有ライブラリ、別名マイクロカーネルとして）
• サービスのアーキタイピング（詳細については、Mavenアーキタイプを探してください）

サービスが六角形のアーキテクチャを実装する場合、別の利点は「アダプター」にあります。これらは別のモジュールに移動でき、抽象化と実装の詳細の間の可能な結合を制限します。同時に、新しいモジュールを並行して実装できます。チームの1人のメンバーはビジネスに焦点を当てていますが、他のメンバーはアダプターに焦点を合わせています。

テストも重要です。これは、小さなモジュールを（時間と複雑さの点で）テストするのとは異なり、サービス全体をテストすることとは異なります。

Answer 2

私はさまざまなプロジェクト構造で働いてきました

1. すべてが同じMavenプロジェクト、単一モジュール、異なるパッケージにあります。
2. あらゆるMavenプロジェクトでのAPIと実装、およびリポジトリもすべてのレイヤーです。
3. 単一のmavenプロジェクトですが、異なるレイヤーのサブモジュールです。

それぞれの長所と短所があります。

最初のアプローチの場合

すべてが単一のプロジェクトにあり、どこからでもすべてにアクセスできます。

例えば。コントローラーは永続エンティティを直接表示して使用できます。階層化を課すエレガントで明白な方法はありません。

インターフェースと実装を別々のパッケージに入れても、コントローラーがAPIのみに依存し、実装に依存しないようにする場合のように、依存関係の反転を実現するのは困難になります。

2番目のアプローチの場合

ここでは、レイヤーごとに異なるソースコードリポジトリがあります。この種の構造により、Mavenを介してレイヤー間の依存関係を管理できるため、非常に適切にレイヤーを作成できます。レイヤー間の依存関係を明確にして、依存関係の逆転を実現できます。

しかし、このアプローチはすぐにMavenプロジェクトとそのCI/CDビルドの爆発を引き起こします。これにより、ユーザーは特定の順序でのみコードをプッシュすることもできます。

番目のアプローチの場合

これは、上記の2つのアプローチの間のスイートスポットのようなものです。

ここには単一のコードリポジトリがあり、複数のリポジトリとビルドを防止しています。サブモジュールのmaven依存関係により、依存関係の逆転によりクリーンな階層化を実現できます。