5

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)?

Robert
  • 545
  • 6
  • 16

1 Answers1

4

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:

Community
  • 1
Christophe
  • 74,672
  • 10
  • 115
  • 187
  • "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 03 '16 at 07: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 03 '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 04 '16 at 08: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 04 '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 04 '16 at 17:50
  • @John What if you'd decide to add a new ms, with a different logic: no user types, but for each user you tell for example the department and the maximum authorized purchase amount. With a decoupled proposal, no pb: every ms is responsible for its authorization scheme. But centralizing is then an issue: should I use a dummy type ? should I combine department x amount ? should I exclude them from the list ? I agree that for every problem we can find a solution. But with the multiplication of dependencies, the ms would no longer be free to evolve independently at their own pace. – Christophe Sep 04 '16 at 18:22
  • @Christophe some services need to evolve, some of them not. You can always break each ms into more smaller ms. There is really no end to it. It's really up to the developer to define his solution space in order to fit the big picture and let his app grow. More dependencies should not be a problem as long as they are not circular and there is a proper context flow diagram – John Sep 05 '16 at 07:50
  • @Christophe imagine you need to get a token for your app. You hit identity ms, pass credentials and after succesfull login, now you want to store some user type/role data inside it (Jwt token for example). How would you figure out what ms to contact or you would contact them all? – John Sep 05 '16 at 08:23
  • @John i'm not sure it's a good idea to store ms roles in the jwt token. Claim of identity would be sufficient attribution of roles to verified identity would be decentralized responsibility (see my other answer in the last link of my reply). But we are slowly slipping in a debate of opinions here: feel free to provide your own answer and suggest a different approach – Christophe Sep 05 '16 at 09:46