モジュール式アプリケーションでフライウェイを使用する

Question

モジュール式のアプリケーションがあり、各アプリケーションは独自のテーブル（通常は2つ）を作成し、データを管理します。

メインアプリケーションではフライウェイを使用していますが、モジュールにも必要です。ただし、メインアプリケーションにパッチを追加すると、対応するモジュールがインストールされていない場合、一部のデプロイメントでALTER TABLEクエリが機能しなくなります。

この問題を解決する1つの方法は、複数の飛行経路操作でスキーマの進化を実行することです。各モジュールは独自の飛行経路を取得し、それ自体を管理します。しかし、Flywayは状態を管理するためのテーブルを作成して以来、私たちは現在〜20個のモジュールを持っているので、テーブルがあまりにも多くなりました。

この問題を解決するにはどうすればよいですか？

Answer 1

私は、サポートしているソフトウェアのユニットによって管理されているマイグレーションが、最もクリーンでトランプ「あまりにも多くのテーブル」であると言います。これらのテーブルのきちんと整理された面では、スキーマ（RDBMSでサポートされているスキーマを使用している場合）を使用してサイロを作成し、マイグレーション・マネージド・アプリケーションごとに使用するテーブルにFlywayを使用できます。

ここで重要なのは「モジュール」です。あなたの説明から、すべてのアプリケーションが同じモジュールで構成されているわけではありません。デカップルされた/再利用可能なソフトウェアを作成するために私たちのモジュールを解体しようとすると、なぜそれらのモジュールのデータベース・スキーマをどう扱わなければならないのでしょうか？

「あまりにも多くのテーブル」について懸念を解消するために、そのコストを試してみましょう。

1. ボリューム。あなたのRDBMSは何千ものものを扱うように作られていますが、コストはかかりません。
2. 操作可能です。フライウェイはここですべての経営陣を務めていますが、彼らは事実上あなたに不透明です。
3. パフォーマンス。これらはデプロイメント上の問題であり、実行時の責任ではありません。
4. 組織。上記の方法でそれらを非表示/名前を付けます。

私たちの自然な衝動は、関連するものを集約することですが、常に最良の結果につながるわけではないので、私たちは実用的でなければなりません。このような状況では、優れた柔軟性のあるデザインが集約よりも優先されます。