bounded contextに従って、我々は2つのマイクロサービスの実装を識別し、それぞれService A
とService B
と呼ぶことができる。これらのマイクロサービスは、それぞれ異なるリポジトリを持っています(単一責任と所有権の利点のため)。現在、これらのリポジトリはそれぞれ独自のデータベーススキーマ(永続性の分離とDBインスタンスのメンテナンスの改善のために選択されたもの)を使用しています。マイクロサービスでは、データベース移行スクリプトとAPIコード用に別々のコードリポジトリを持つことは理にかなっていますか?
これまで、データベース移行スクリプト(連続配信用)を個別の単一リポジトリ(Service A
とService B
のスキーマの両方のスクリプトを含む)に抽出し、CIの下で単一のジョブで実行しました。我々はより多くの物語に取り組むようになりました、私たちは、以下に列挙されているそのうちのいくつかは、いくつかの課題に直面し始めている:
- 単一のスキーマへの変更は、データベース全体、ひいては全てmicroservicesの下流トリガするためのビルドをトリガし、スキーマの変更も
Service
コード内のそれぞれの変更を必要とするので、慎重な努力がさらにPRs - の両方を展開するために取られ、そこにあるので、それゆえ
- 私たちのフィードバック時間を増加我々は、
true
連続送達を達成するために失敗し、一般的にありますUsers
のようないくつかの一般的なテーブルは、どちらのスキーマにも複製されています。
だから私の質問/疑問です。
- 私たちも、ちょうどサービスのように、スキーマに従って、DB移行リポジトリを分離する必要があります。
- DB移行スクリプト用に別のリポジトリを用意する必要がありますか?私たちはそれぞれの
Service
レポジトリコード内でクラブを結成すべきですか? - 我々はさらに
a level up
共通のテーブルを抽出し、Eventual Consistency
ためDomain Events
に任意のポインタ/アドバイスでしょう大幅help.Thanksを大きくする必要があります。
ありがとうございました。だからあなたは共通のテーブルのために何を提案しますか?ユーザーのような?両方のスキーマで監査履歴を維持する必要があるため、参照整合性のためのユーザー表の要件が必要です。このユーザテーブルは、サービスに限定されたコンテキストの下に落ちるのでしょうか、それとも独自のものですか? –
私はアップデートを提供しました。 –