Spring Modulith ランタイムサポート
前の章で説明した機能はすべて、検証とドキュメント作成の目的でテストシナリオでアプリケーションモジュール配置を使用していたか、モジュールを疎結合するのに役立つ一般的なサポート機能でしたが、アプリケーションモジュール構造では直接機能しませんでした。このセクションでは、アプリケーション実行時のモジュール初期化に対する Spring Modulith のサポートについて説明します。
| ここで説明するアプリケーションモジュール検出にカスタマイズを適用する場合は、カスタマイズがすでに存在している場合を除き、本番ソースに移動して、ここで説明する機能によって考慮されるようにする必要があります。 |
アプリケーションモジュールのランタイムサポートのセットアップ
Spring Modulith のランタイムサポートを有効にするには、プロジェクトに spring-modulith-runtime JAR を含めるようにしてください。
この JAR を追加すると、アプリケーションに次のコンポーネントを登録する Spring Boot 自動構成が実行されます。
ApplicationModulesへのアクセスを許可するApplicationModulesRuntime。メインアプリケーションクラスを検出するために、以前の Bean をサポートする
SpringBootApplicationRuntime。spring.modulith.runtime.verification-enabledがtrueに設定されている場合にのみ、起動時にアプリケーションモジュールの配置を検証し、違反が検出された場合に中止するRuntimeApplicationModuleVerifier。アプリケーションコンテキストで定義された
ApplicationModuleInitializerBean を呼び出すApplicationStartedEventのイベントリスナー。
アプリケーションモジュール初期化子
アプリケーションモジュールを使用する場合、アプリケーションの起動時に個々のモジュールに固有のコードを実行する必要があることがよくあります。これは、コードの実行順序がアプリケーションモジュールの依存構造に従う必要があることを意味します。モジュール B がモジュール A に依存している場合、イニシャライザーが別のイニシャライザーに直接依存していない場合でも、A の初期化コードは B の初期化コードより前に実行する必要があります。
もちろん、開発者は Spring の標準 @Order アノテーションまたは Ordered インターフェースを介して実行順序を定義できますが、Spring Modulith はアプリケーションの起動時に実行される Bean 用の ApplicationModuleInitializer インターフェースを提供します。これらの Bean の実行順序は、アプリケーションモジュールの依存関係構造に自動的に従います。
Java
Kotlin
@Component
class MyInitializer implements ApplicationModuleInitializer {
@Override
public void initialize() {
// Initialization code goes here
}
}
@Component
class MyInitializer : ApplicationModuleInitializer {
override fun initialize() {
// Initialization code goes here
}
}
ApplicationModuleInitializer Bean は、spring-modulith-runtime JAR がクラスパス上にある場合にのみ呼び出されることに注意してください ( アプリケーションモジュールのランタイムサポートのセットアップを参照)。これは、アプリケーションモジュール構造に従って初期化子をトポロジ的に並べ替えるために必要な依存関係を取得するためです。
アプリケーションモジュール対応の Flyway 移行
Spring Modulith 2.0 以降、モジュール固有の Flyway の移行の実行をサポートしています。アプリケーションモジュールは、自身の永続データのみの移行を定義することが推奨されています。つまり、これらの移行はモジュール依存関係ツリーの順序に従って実行する必要があります。
移行が classpath:db/migration に配置され、アプリケーションモジュールが 2 つ first と second (second は first に依存)、構成プロパティがアクティブ化されたデフォルトの Flyway セットアップを想定します。
これを踏まえて、Flyway のセットアップを次のようにカスタマイズします。
ルート移行フォルダーは
db/migration/__rootに変更されます。この際、デフォルトのバージョン追跡テーブルが使用されます。db/migration/$moduleIdentifierの追加移行は、flyway_schema_history_$moduleIdentifierの追跡テーブルに登録されます。これらの移行もベースラインバージョン 0 に設定され、移行時にベースラインとして設定されます。ワイルドカードで終わる移行場所はカスタマイズされません。
移行スクリプトで使用されるバージョン番号は、実質的にアプリケーションモジュールにスコープ指定されており、グローバル順序付けを使用しないことに注意してください。
マイグレーションファイルを保存するフォルダーを選択することで、常に実行されるマイグレーションと、対応するモジュールに対してのみ実行されるマイグレーションを区別できます。アプリケーションモジュールのテスト統合では、デフォルトのマイグレーションと、テスト実行に含まれるモジュールのマイグレーションのみが実行されます。