information hiding is a concept where you don't put information on the interface that are likely to change, thus making your microservice independently deployable and stand alone
-
Information hiding (aka encapsulation aka decoupling): you hide the parts of the application that are most likely to change, thus protecting other parts of the program from extensive modification, if the design decision is changed.
-
Information hiding is the ability to prevent certain aspects of a class or software component from being accessible to its clients (like private variables), thus minimises the blast radius.
-
Information hiding makes your app independently deployable, more modular.
-
Any information (e.g. interface, swagger, function, method, property, object, data structure) that you expose outside of your microservice boundary, an external consumer will make use of that. You try and limit what you expose so that you minimize the affect to your consumer if you ever change the interface to your microservice. Once your consumers make use of that, you effectively have a contract. Once the consumer has an expectation about how that interface works, then it makes it harder for you to change your microservice without breaking them.
-
Use information hiding if you want independent deployability of your microservice and backward compatiblity.
-
by hiding things inside your service boundary, the things inside your service boundary can change without fear of breaking your external consumers.
-
encapsulationis things that are hidden that can change easily. Things that are shared are part of your contract. The more you hide, the more freedom you have to change things safely inside your microservice.