マイクロサービスの多対多の関連付け

現在、2つのマイクロサービスがあります。私たちはそれらAを呼び出しますB。

マイクロサービス下のデータベースにAは次の表があります。

A
|-- users

マイクロサービス下のデータベースにBは次の表があります。

B
|-- trackers

要件にはそれが明記されusersてtrackersおり、多対多の関係があります。

マイクロサービスアーキテクチャ内でこれを適切に処理する方法がわかりません。

これは、次の3つの方法のいずれかで動作することがわかりました。

1. user_trackersテーブルには、microserviceに追加されますA。これは、「外部キー」への参加を含むテーブルに似た働きusersとtrackers。
2. ownersテーブルには、microserviceに追加されますB。このテーブルは、ポリモーフィック結合テーブルと同様に機能します。これにより、どのサービスでもトラッカーとの関連付けを作成できます。これは次のようになります。 B |-- trackers |-- owners |-- owner_id |-- owner_type |-- tracker_id
3. レコードキープusersし、trackers各microserviceでは。ある種のpubsubシステムと同期してください。

もともとオプション2を使用するつもりだったのは、トランザクションの境界が保存されていることが気に入ったからです。トラッカーを作成して、それをアトミックに関連付けることができます。ただし、microserviceの範囲外のようBです。BマイクロサービスAが関連付けを作成することをマイクロサービスが気にする必要があるのはなぜですか？

ここにはおそらく気付いていない良いパターンがあるように感じます。私がレイアウトしたオプションのいずれかが意味をなしますか？より意味のある別のオプションはありますか？

まず、ドメインの説明から始めます。あなたはそれが何であるかについて言及していません（私は推測できますが、それは推測に過ぎません）。その後、バリューチェーン分析またはビジネス能力マッピングを使用して分解しようとします。そして、その後になって初めて実装について考えました。

あなたの問題を考えると、私の頭に浮かぶ最初のことは、単にお互いのデータが必要だからといって、サービスの境界を間違って特定したということです。あなたがで終わるしたくない分散型モノリス、あなたは何？

2番目のことは、おそらくドメインを十分に操作していないことです。usersテーブルで表される概念は何ですか？それはregistered user登録に必要なすべての情報と行動で、？trackers（それが何であれ）と通信するための正しい概念であると確信していますか？ですから、私がそれを正しく理解したなら、あなたの選択肢2はまさにそれについてです：ownerあなたのドメインにより近い概念を導入します。本当にそうなら、私もオプション2を選択します。

ただし、マイクロサービスBの範囲外のようです。マイクロサービスAがアソシエーションを作成することをマイクロサービスBが気にする必要があるのはなぜですか。

それはすべて境界です。エンティティの周りにマイクロサービスを形成したいと思います。そこで階層化されたサービスアーキテクチャでSOAが失敗しました。より良いアプローチは、ビジネス機能を表すサービスを作成して、データと動作の両方をカプセル化することです。より実用的な観点からは、ビジネスプロセスまたはユースケースに関連するサービスを作成することです。たとえば、ユーザー登録用のサービスを1つ持つことができます。ユーザーを登録するために必要なユーザーのデータと動作が含まれています。したがって、の概念は自然に形成され、サービスAのみに属します。そして、これは次のポイントに私を連れて行きます：サービスについて考えるもう1つの方法は境界コンテキストです。サービスと制限されたコンテキストを調整することをお勧めします。user

ユーザーが登録されると、UserCreatedイベントが発行される可能性があります。私が推測するあなたの2番目のサービスはそれに興味があります。したがって、それを受信すると、まったく別のエンティティ、たとえばOwnerエンティティ（いずれでも）を作成できます。trackerエンティティとエンティティの間に多くの興味深いコラボレーションがあることを確信しています-それらを単一のサービスに保持します。

オプション3には非常に注意してください。データをコピーすると、機能が続きます。密結合になります。また、CQRSの用語はカバーしません。イベントを介したサービス間のデータ同期に関するものではありません。

Zapadloの答えには、多くの優れた情報と推論が含まれています。ここで、実際のアドバイスを追加して、問題やその回答のアドバイスを簡単に理解できるようにします。

設計の質問を組み立てる方法は、データベース構造と、それに対する構造の新しい要件の適合方法に関するものです。これは、データモデルからサービス設計を構築していることを意味します。たとえば、表示されないのは、ユーザーとトラッカーの関係がどのようにアクセスまたは使用されるかです。

サービス設計では、インターフェースの構造が設計の最も重要なものです。実際、特にマイクロサービスの場合には、比較はほとんど関係ありません。その理由は、サービスを適切に配置すると、サービスへのすべての依存関係がインターフェイスのみに存在するようになるためです。正しく理解できれば、消費者なしで実装を完全に書き直すことができるはずです。そして、それが自律性の主な利点です。あなたがそれをどのように構築したかは誰も気にしません。彼らはあなたが伝えた通りに働くためにそれを必要とします。

これがデータベース内でどのように見えるか、またはこれをどこで望むかを決定する前に、この情報がどのように使用されるかを本当に説明する必要があります。これはサービスを通じて公開されるものですか、それとも分析のためにシャッフルしたいデータですか？

補足として、私はほとんどすべてのコストで双方向の依存関係を避けます。依存関係がある場合、実際に一方の側だけが他方の側について知っておく必要があります。依存関係が双方向になると、それらのサービスは基本的にアトミックユニットになります。

その多くは、ドメイン自体に帰着します。トラッカーがないユーザーが意味をなさない場合、ユーザーサービスはトラッカーについて知る必要があります。トラッカーにユーザーが必要な場合、トラッカーはユーザーについて知る必要があります。複数の所有者がいるトラッカーを持っている、またはあるユーザーから別のユーザーにトラッカーを転送できるなどのことが理にかなっている場合、この情報はさらに別のサービスに属している可能性があります。

質問：データテーブルに沿ってデータが分離されているのはなぜですか？

私はオプション3に行く傾向があります：サービスは完全に分離されており、答える必要があるかもしれないそれぞれの質問に答えることができます。さらに、彼らははるかに弾力性があります。ただし、イベントが失われた場合、サービスの同期が解除される可能性がありますが、結果の一貫性により解決できます。

また、両方のサービスをマージすることを検討することもできます-両方がお互いを知らずに応答できない場合、それらはおそらく単一のドメインの一部であるため、それらをマージします。