Microservices dependencies in UML diagrams

Question

I want to explain how microservices depend on each other.
Consider for example, the following case:

The user service exposes the user_detail endpoint;

The product service exposes the product_item_detail endpoint;

The ordering service exposes the make_order endpoint.

The user selects a product and places an order.

How can this be explained using UML diagrams?

I had planned to use a component diagram but I don't understand how to explain the interfaces of each service and how they relate to the interfaces of the other services. Is there a way to do this, or should a more suitable type of diagram be considered?

Bichromate

Are you interested in the static dependencies (endpoints exposed/consumed)? Or the dynamic interactions that you describe in the last sentence of your case? – Piperonal

I interested in static dependencies . thank you – Bichromate

Ideally you want to avoid microservices being dependend on each other at all. The whole point of microservices is to decouple your services. – Facultative

@tomredfern technically speaking, OP is looking for dependencies on API interfaces, so the microservices stay decoupled: a microservice could be exchanged by an equivalent one offering the same interface, and the wiring could even be done dynamically using some service discovery – Piperonal

This seems a relevant question, I vote to reopen it. The initial wording used "best diagram" and mislead to think that it was opinion-based, whereas the problem was in fact exposed in objective terms and called for an objective solution. I reworded accordingly. – Piperonal

Answer 1

Microservices are independently deployable components. Therefore, using a component diagram appears a very good intuition:

It specifies a Component as a modular unit with well-defined Interfaces that is replaceable within its environment. The Component concept addresses the area of component-based development and component-based system structuring (...).

In your component diagram each microservice would be shown as a separate component with the stereotype «service». Since microservices do not just implement an interface but expose it via an endpoint, you should make use of ports:

Ports represent interaction points through which an EncapsulatedClassifier communicates with its environment.

Interfaces provided or required (lollipops and sockets) would be connected to ports. The port make the difference: without the port, lollipops and sockets could as well mean a realisation or a «use» dependency to an interface classifier within a big monolith!

In the end your diagram could look somewhat like:

Additional thoughts:

• If you hesitate between «service» and «subsystem» stereotype, you may consider creating your own UML profile that defines a «microservice» stereotype.

• If in some complex diagram you do not want to show the detail of the service endpoints, you may just use an assembly connector without socket/lollipop except where you want to put the focus.

• Similarly, if you are mainly interested in the dependency, you may just show the component and their dependency relation (since components are classifiers).

• If you think of microservices, you will inevitably think of scaling strategies, such as for example having several instances of the same service running on several containers/servers, or heving several instances of the same microservice partition the data. This kind of though is about deployment scenarios of the components. You may then consider deployment diagrams. But this goes far beyond your question.

Piperonal

Could you please make a similar schema but for the data flow between microservices? – Neilneila

@Neilneila Technically you'll have to chose between "object" flows and "message" flows. My first guess would be to use a sequence diagram, or a communication diagram. Both show the exchange of "messages" between objects or instances of components (i.e for a sequence diagram, the lifeline would be a microservice). I let you google for the graphical representation. Alternatively, you could open a more precise question. – Piperonal