Microservices governance vs SOA

whether you enforce contracts is independent of if you connect through the service bus or directly. You could build your microservices to use SOAP and WSDL. The industry as a whole seems to be moving away from this.

The team responsible for deploying the microservice needs to treat all external parties like customers. This means when changes occur, they need to keep backwards compatibility and then undergo a change management process in other teams to have them upgrade before decommissioning the old version. We avoid breaking changes as much as possible, and use semantic versioning otherwise. Automated tests help keep all this possible.

In terms of governance, I would set ground-rules around the following:

• what is (and is not) considered a breaking change, and how this is to be handled in the versioning system
• how/where documentation for services is to be published and updated
• how clients are to authenticate themselves
• security recommendations such as TLS and authentication mechanisms

While you may not have a canonical data model covering all services, it could be wise to introduce some smaller conventions suitable to your domain. In my domain, this means always using 3-character ISO standard currency codes alongside monetary amounts. We never assume the currency or use a different representation.

Source: StackOverflow