Orchestrating microservices

Question

What is the standard pattern of orchestrating microservices?

If a microservice only knows about its own domain, but there is a flow of data that requires that multip

Answer 1

So you're having two services:

1. Invoice micro service
2. Shipment micro service

In real life, you would have something where you hold the order state. Let's call it order service. Next you have order processing use cases, which know what to do when the order transitions from one state to another. All these services contain a certain set of data, and now you need something else, that does all the coordination. This might be:

• A simple GUI knowing all your services and implementing the use cases ("I'm done" calls the shipment service)
• A business process engine, which waits for an "I'm done" event. This engine implements the use cases and the flow.
• An orchestration micro service, let's say the order processing service itself that knows the flow/use cases of your domain
• Anything else I did not think about yet

The main point with this is that the control is external. This is because all your application components are individual building blocks, loosely coupled. If your use cases change, you have to alter one component in one place, which is the orchestration component. If you add a different order flow, you can easily add another orchestrator that does not interfere with the first one. The micro service thinking is not only about scalability and doing fancy REST API's but also about a clear structure, reduced dependencies between components and reuse of common data and functionality that are shared throughout your business.

HTH, Mark