Is having user-type per micro-service good approach?Example:Users in identity management context can have one of predefined user_types:affiliate_userb2b_useraccomodation_owneragentadminBut 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)?
Microservices and user roles
architecture;domain driven design;microservices
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:  an article of interest on this topic a slightly different question, but somehow related to yours (Edit: Oh ! It's yours !  I leave it here for the other readers ;-) )