「ユーザー」マイクロサービスは良い考えですか？

私はマイクロサービスに不慣れです。私の理解から、DDDはビジネスドメインを中心にマイクロサービスを構築するように言っています。つまり、会議予約システムのコンテキストでは、優れたマイクロサービスはAppointmentSchedulerやSendNotificationのようなものです。

この例では、これらの両方のマイクロサービスがビジネス機能を果たすためにユーザーデータにアクセスする必要があり、それを提供するための最良の方法に苦労しています。

私には、ユーザーはマイクロサービス内のエンティティとして存在する必要があるオブジェクトのように見えますが、ほとんどすべてのマイクロサービスに存在する必要があります。これにより、多くの重複が発生します。

もう1つのオプションは、ユーザーデータベースでCRUD操作を提供するユーザーマイクロサービスを用意することです。これは、他のマイクロサービスがユーザーデータにアクセスするために使用できますが、私が抱えている問題は、分散モノリスになるまでサービスを密結合することです。これは、モノリス自体よりもわずかに優れています。

私の推論は有効に見えますか？他の人はどのように問題に対処していますか？

ほとんどのマイクロサービスで同じユーザーオブジェクト/モデル/レコードが本当に必要な場合は、おそらく個別のマイクロサービスはまったく必要ないか、知識が及ぶ限り、オブジェクトにとらわれないはずです。したがって、各マイクロサービスは、機能に必要なデータとそのユーザーを区別するために使用されるキーを使用して、ユーザーモデルのサブタイプを管理します。理想的な世界では、この方法で必要な変更を実行し、何らかのイベントブローカーを介してシステム全体に変更を伝達できます（イベント駆動型のアーキテクチャーがあると想定）。そうでない場合、各サービスはいくつかの（またはすべて）他のサービスとそれらが何をするつもりか、そして彼らが受け取ることを期待するオブジェクトのタイプ。

真のマイクロサービス環境では、各マイクロサービスには、システムの他の部分から分離された独自のデータストアが必要であり、ユーザーエンティティの概念を完全にダンプする必要があるという私の最初のステートメントをバックアップすることに注意してください。

たとえば、SendNotificationマイクロサービスは、WebSocket識別子を持つオブジェクト（サービス全体に渡され、最終的にはこのオブジェクトに到達します）とユーザーに返されるはずのデータのみを受け取り、必要なフィールドを確認するだけです。そこにあり、WS識別子によって適切なチャネルに通知をプッシュします。処理するオブジェクトの種類をまったく知る必要はありません。