I work in a small company and we are about to delve into the Microservices world. As expected, we are hitting a few bumps.
Let us focus on a small bounded context: work order.
This bounded context is composed of a technician, a team and the actual work order. A team is composed of a group of technicians and a team manager, who is also a technician.
One aspect of the software: a technician should be able to see all the work orders issued to them and, if they happen to be the manager of a team, they should be able to see all the work orders issued to any members of that team.
Should I create a single service, or two: one to manage the teams and technicians and one to actually manage the work orders. The problem with the second approach is that part of the logic that controls which orders should be retrieved will have to be placed inside the API Gateway / BFF.
As the work orders have no knowledge of teams (which I actually think it is the correct design), the API Gateway would have to retrieve the teams in which the technician is the manager in order to retrieve all the work orders for all members of those teams.
My concern here is that it seems some business logic is leaking to the API Gateway and I am not sure that is all right. I am also afraid of creating anemic microservices. On the other hand, this bounded context might be used on a different software, which may not make use of the concept of teams.
I also thought about creating a third service to coordinate this work but have not found any reasons to support the idea as of now.
So, to summarize: should I create one, two or three services? I am bound to creating two, but cannot seem to decide just yet.