In this post, we briefly talk about modeling microservices. microservices are just another form of modular decomposition one that has network-based interaction between the models and all the associated challenges that brings. Now let us delve into three concepts we talked about in previous posts.

Information Hiding

Information hiding describes a desire to hide as many details as possible behind a module boundary.
With information hiding we achieve:

• Improved development time by allowing modules to be developed independently, we can allow for more work to be done in parallel and reduce the impact of adding more developers to a project.
• Comprehensibility Each module can be looked at in isolation and understood in isolation. That makes the system easy to understand.
• Flexibility by being able to change modules independently and mix them to create new functionality. To achieve the above characteristics, it lot depends on how the module boundaries are formed. Information hiding was a key technique to help get the most out of modular architectures, and with a modern eye, the same applies to microservices too.

Cohesion

The code that changes together, stays together. we’re optimizing our microservice architecture around the ease of making changes in business functionality—so we want the functionality grouped in such a way that we can make changes in as few places as possible. We want related behavior to sit together. If the related functionality is spread across the system, we say that cohesion is weak—whereas for our microservice architectures, we’re aiming for strong cohesion.

Coupling

The whole point of a microservice is being able to make a change to one service and deploy it without needing to change any other part of the system. This is really quite important. A loosely coupled service knows as little as it needs to about the services with which it collaborates.

In the next post, we will talk deeply about coupling.