How to draw use case diagram based on microservice architecture?

Question

I want to develop a web application based on Microservice architecture.So,I have drawn use case diagram describing functional requirements of the system, but I am not sure whether is it correct or not?

My system has three Microservices. The first one called "shop service" which is the main service that is responsible for everything happens at the online-shop: viewing product catalog, adding product to cart, filling in order information. It is represented as a rectangle on my diagram all the business processes(functions) happen within it.

The second one is bank service that is responsible for making payments using customer's bank account.

The third one is postal service that is responsible for delivering orders to customers to be able to receive it.

I have six actors. I also divide them into the primary and the secondary ones. The primary ones which are on the left initiate the use of the system, on the other hand, the secondary ones are more reactionary.

What would you recommend me to do my system to become more readable and understood for everyone? Should I add or delete something? Here is my attached diagram:

I apologize for all mistakes I have made asking the current question. Sorry for my bad English as well.

Answer 1

Except for Log in that looks ok. Log in is no use case (no added value for the actor) but a simple constraint attached to certain UCs which need the authentication.

In order to group your microservices you could introduce different systems under consideration reflecting the specific microservices. The use cases related to each microservice would then appear inside the boundary reflecting the specific microservice.

On a further notice: UCs that are only attached to secondary actors (appearing to the right) I would consider them not being UCs but just a flow of events in the including UC. UCs are meant to show added value the system under consideration brings to its primary actor. The way you did it is just functional decomposition. That's not what UCs are all about.

And as always I recommend to read Bittner/Spence about use cases.