2 つのビジネス コンポーネントがあるとします。
これはユーザーを所有しています。ユーザー情報が変更されると、このコンポーネントはメッセージを発行します。たとえば、「NewUserCreated」
ユーザーとのやり取りを処理します。電子メール、ツイートなど。したがって、このコンポーネントはユーザー メッセージをサブスクライブし、その情報のサブセットを独自のストアに格納します。
User Management コンポーネントが Publications コンポーネントの前にオンラインになるとどうなりますか? Publications はどのようにして既存のユーザーのリストを取得しますか? ユーザー管理コンポーネントがそのデータをどのように保存するかを認識しないでください。
ユーザー管理とパブリケーションがBCであるかどうかはわかりませんが、エンティティの2つのサブセットではなく、異なるビジネス機能を提供するため、異なるサービスまたはACです。
UserエンティティのサブセットをPublicationsサービスに保存すると、サービスの臭いがする可能性があります。相関ID（userId）を除いて、2つのサービス間でデータの重複がないようにする必要があります。
パブリケーションサービスには、すべてのユーザーのリストは必要ありません。
メンテナンスやバージョン更新などの短いサーバーダウンタイムについて話している場合、UserManagementサービスから送信されたメッセージは、送信キュー（または構成されたタイムアウト後のエラーキュー）で利用可能になり、Publicationsサービスに再送信できます。以前のデータは、Publicationsデータストアにある必要があります。
別のシナリオについて考えてみましょう。たとえば、システムを1年間実行していて、パブリケーションサービスの機能を使用せずに、その間ずっとユーザー情報を収集しているとします。ここで、数百万のユーザーがいる後、新しいパブリケーションサービスを追加します。
最初は、そこにデータはありません。システムの現在のユーザーがログインすると、パブリケーションの詳細（Eメール、Twitter、Facebookアカウントなど）を入力する新しいページが表示される場合があります。これにより、パブリケーションサービスデータに新しいエントリが作成されます（関連するユーザーID）。新規ユーザーは、サインイン時にパブリケーションサービスデータストアにデータを追加します（必要な場合）。
それは役に立ちますか？
他の統合プロジェクトと同様に、新しいシステムが起動する前に必要な関連データを取得する ETL 手順を選択するだけです。
それは一度限りの出来事なので、問題を複雑にする必要はありません:)
moranlf が言っているように、ユーザー管理とパブリケーションは 2 つの異なるサービスのように見えます。2 つの間でデータの重複があってはなりません。
パブリケーションは、よく知られている Amazon のアナロジーで言えば、配送サービスのようなものです。ユーザー エンティティ (住所) に関するデータを保持しますが、それはそれ自身の/担当するデータのみを保持します (両方に共通の userId は別として)。ユーザー管理サービスから公開されたイベントは、サブスクリプション サービスにデータを「作成」しません。ポリシー/サガを開始し、ハンドラーをトリガーする可能性がありますが、それ以上のことはありません。
ここに 2 つのシナリオ:
それは役に立ちますか？