SITUATION
Let's assume we want to generate an excel report with the data from microservice A and present it in microservice B. We can obtain the data with some scheduled task or so.
POSSIBLE SOLUTIONS
Simplest
We add a report functionality to microservice B and generate reports there.
Pros:
Pretty strightforward, on the fly generation (no need to store files)
Cons:
In my opinion it is a violation of bounded context. We mix two functionalities although actually one uses another.
Extracting new microservice dedicated for reports
We create a microservice C which gather data aggregates for reports from A and serve it for B.
Pros:
Separation of responsibilities. In my opinion bounded context is not violated.
Cons:
Either you have to send a generated excel file between microservices (awful idea) or aggregates (not ideal too). The solution for this could be generating a link to the document and send this to B to redirect the user. This seems to be nice idea but on the other hand we need to store the generated document (in opposite to on the fly generation).
What is your experience in simillar situations? Maybe someone has another approach?
UPDATE
I am adding a sketch to better illustrate an actual problem.
Best Answer
OK, This is not a problem of bounded contexts.
You can have more than one service in a bounded context, and its impossible to say what should go in what context when you abstract the functionality to simple names like "A" and "B".
The key thing to realise is that micro services should be micro or even nano
your preference should generally be to add a new service rather than to expand an existing one.
Edit - summary of comments:
The consuming application should make the call directly to the micro-service. If extra info is required, the consuming api should preferably call the requisite micro-services to build that data first, and then send it to the report micro-service.
Cross cutting concerns like authorisation/authentication can be handled by generating a signed token rather than having a single auth service which all the other services depend on.
In this way you avoid building a 'distributed monolith' of services with them all linked and talking to each other.