4

Is having user-type per micro-service good approach?

Example:

Users in identity management context can have one of predefined user_types:

affiliate_user
b2b_user
accomodation_owner
agent
admin

But looking from the perspective of support bounded context, it cares only about agents (people who are answering tickets), and end_users (people who are asking questions).

If newly created user inside identity BC is accommodation_owner, he will be replicated to supporting bc as end_user, cause he can only ask for help.

Is this good or bad design practice? What if i need to list all agents, so I can assign a ticket.

Should I query identity microservice for users with certain user_type, or should i query supporting microservice to list me all users with type agent (/api/support/agents)?

3

From your explanation, I understand that you have a microservice for managing user identity (user account, logon) and what you call "user type" in the other microservices correspond to an authorization role (i.e. what a user having this type can do in the microservice).

Separating user and authorization, and having authorization managed in each microservice seems to be a good architecture :

  • each microservice could evolve at its own pace
  • you don't create an unnecessary dependency between the user identity service and the other microservices (if you would maintain a global list of roles/authorization you would couple the services)
  • you could add new microservices without having to worry about the other ones.

Of course, you'd keep the benefit of loose coupling only if you keep the dependencies to their strict minimum:

  • Every microservice should provide a query on "user types". Of course replicating these in the identity service would make query easier, but it would kill benefits of microservices.
  • Replicating of user info to the consuming services should also be kept to the minimum: user id should be sufficient. Anything else should be queried from user identity service.

Here some additional reading:

  • "Replicating of user info to the consuming services should also be kept to the minimum: user id should be sufficient. Anything else should be queried from user identity service" . What if you want to list all agents from the support. Would you do that from supporting ms? – Robert Sep 3 '16 at 7:39
  • 1
    @Robert I don't have the full picture of your service landscape, but yes, it seems logic: support ms is responsible for support, so it's the starting place to find support user ids. If more is needed, more shall be queried to user identity (but this overhead shall not be part of your API: you could perfectly have another ms wondering if one of its own user is also a support user without bothering for the names, email addresses or other identity info). If many of your apps are displaying lists of users and requiring this kind of data composition, you could make this an horizontal service. – Christophe Sep 3 '16 at 10:39
  • @Christophe what do you mean by Of course replicating these in the identity service would make query easier, but it would kill benefits of ? – John Sep 4 '16 at 8:50
  • @John if you'd replicate all the user types in the identity service, you can query there in one ms all the elements that you are looking for. But then what if two ms have by accident the same naming of a user-type: do you consider it's the same type, or is the type dependent of the consuming service ? And what if one ms considers that a user can have several types ? In fact, you create there a mutual dependency between the identity service and the other services, that will make independent evolution difficult. – Christophe Sep 4 '16 at 12:04
  • @Christophe I am just following your first reply. You mentioned it would kill the benefits of MS. I was curious to hear what would be the benefits. In your last reply you provided remarks that all make sense, but could all be resolved with a proper design in one MS ie. identity. Your remark, that if services are decoupled, no inconsistencies should be present (same data, different meaning) is the most important advice here. – John Sep 4 '16 at 17:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.