マイクロサービスでは、データベース移行スクリプトとAPIコード用に別々のコードリポジトリを持つことは理にかなっていますか？

Question

bounded contextに従って、我々は2つのマイクロサービスの実装を識別し、それぞれService AとService Bと呼ぶことができる。これらのマイクロサービスは、それぞれ異なるリポジトリを持っています（単一責任と所有権の利点のため）。現在、これらのリポジトリはそれぞれ独自のデータベーススキーマ（永続性の分離とDBインスタンスのメンテナンスの改善のために選択されたもの）を使用しています。

これまで、データベース移行スクリプト（連続配信用）を個別の単一リポジトリ（Service AとService Bのスキーマの両方のスクリプトを含む）に抽出し、CIの下で単一のジョブで実行しました。我々はより多くの物語に取り組むようになりました、私たちは、以下に列挙されているそのうちのいくつかは、いくつかの課題に直面し始めている：

• 単一のスキーマへの変更は、データベース全体、ひいては全てmicroservicesの下流トリガするためのビルドをトリガし、スキーマの変更もServiceコード内のそれぞれの変更を必要とするので、慎重な努力がさらにPRs
• の両方を展開するために取られ、そこにあるので、それゆえ
• 私たちのフィードバック時間を増加我々は、true連続送達を達成するために失敗し、一般的にありますUsersのようないくつかの一般的なテーブルは、どちらのスキーマにも複製されています。

だから私の質問/疑問です。

• 私たちも、ちょうどサービスのように、スキーマに従って、DB移行リポジトリを分離する必要があります。
• DB移行スクリプト用に別のリポジトリを用意する必要がありますか？私たちはそれぞれのServiceレポジトリコード内でクラブを結成すべきですか？
• 我々はさらにa level up共通のテーブルを抽出し、Eventual Consistency

ためDomain Eventsに任意のポインタ/アドバイスでしょう大幅help.Thanksを大きくする必要があります。

Answer 1

それぞれのコードリポジトリで移行を維持することを検討する必要があります。サービスAにはサービスBとは独立した独自の移行セットが必要です。これにより、サービスAを展開し、サービスBに関係なくAのスキーマを移行できます。

また、共通テーブルを持たないことを検討する必要があります。共通の表には深刻な欠点があります。サービスAがサービスBを中断する方法でユーザーを変更する必要がある場合、分散モノリスが作成されています。

---

UPDATE 1：

は、監査ログを構築する強力な参照整合性を必要としない場合があります。代わりにソフトの外部キーを考えることができます。

マイクロサービスをどのように設計するかは、ドメインに依存しています。 Userが認証されたユーザーである場合は、まず認証のクロスカッティングの問題に取り組む必要があります。認証されたユーザーが誰か、何らかのアクションを実行する権限があるかどうかを判断するために、jwtなどの認証トークンを要求するように各マイクロサービスに選択できます。次に、監査ログでユーザーのIDを使用するだけです。

ユーザーが「サービスの限定されたコンテキストに該当する」かどうかは、そうではない可能性があります。つまり、Userに対する更新はService Aにどのようにバインドされていますか？あなたはおそらく、ユーザーがサービスAに従属しているとは考えていませんし、サービスAに対するアクションを介してユーザーを更新したいとは思わないでしょう。