web-dev-qa-db-ja.com

マイクロサービスとユーザーの役割

マイクロサービスごとにユーザータイプを使用することは良いアプローチですか？

例：

ID管理コンテキストのユーザーは、事前定義されたuser_typesの1つを持つことができます。

affiliate_user
b2b_user
accomodation_owner
agent
admin

しかし、サポート境界のコンテキストの観点から見ると、それはエージェント（チケットに答えている人々）とend_users（質問している人々）だけに関心があります。

ID BC内で新しく作成されたユーザーがAccommodation_ownerである場合、彼はサポートBCにend_userとしてレプリケートされます。これは、彼が助けを求めることしかできないためです。

これは良い設計か悪い設計か？チケットを割り当てることができるように、すべてのエージェントをリストする必要がある場合はどうなりますか？.

特定のuser_typeのユーザーのIDマイクロサービスをクエリする必要がありますか、それともサポートマイクロサービスをクエリして、タイプエージェント（/api/support/agents）？

architecturedomain-driven-designmicroservices
5
Robert

あなたの説明から、ユーザーID（ユーザーアカウント、ログオン）を管理するためのマイクロサービスがあり、他のマイクロサービスで「ユーザータイプ」と呼んでいるものは承認の役割に対応している（つまり、このタイプのユーザーができること）マイクロサービス）。

ユーザーと承認を分離し、各マイクロサービスで承認を管理することは、優れたアーキテクチャのようです。

  • 各マイクロサービスは独自のペースで進化する可能性があります
  • ユーザーIDサービスと他のマイクロサービスの間に不要な依存関係を作成しない（ロール/承認のグローバルリストを維持する場合は、サービスを結合する）
  • 他のサービスを気にすることなく、新しいマイクロサービスを追加できます。

もちろん、依存関係を最小限に抑えた場合にのみ、疎結合の利点を維持できます。

  • すべてのマイクロサービスは、「ユーザータイプ」に関するクエリを提供する必要があります。もちろん、これらをアイデンティティサービスで複製するとクエリが簡単になりますが、マイクロサービスの利点が失われます。
  • 消費するサービスへのユーザー情報の複製も最小限に抑える必要があります。ユーザーIDで十分です。それ以外は、ユーザーIDサービスから照会する必要があります。

ここでいくつかの追加の読書：

3
Christophe