𝐌𝐢𝐜𝐫𝐨𝐬𝐞𝐫𝐯𝐢𝐜𝐞 𝐃𝐞𝐬𝐢𝐠𝐧 𝐏𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞𝐬

Microservice architecture is a software architecture pattern where a system is designed as a network of loosely coupled services.
It is a way of building software that can be scaled independently and that can be developed, deployed, and updated more rapidly than traditional monolithic applications.

This article covers:

• Single Concern Principle
• Interface Segregation Principle
• Loose Coupling Principle (High Cohesion and Low Coupling)
• Autonomy Principle
• Discrete Boundaries Principle
• Event Driven Principle

Here is the list of principles that programmers should abide by to build Microservices-based applications that are adaptable, scalable, and high performant.

𝐌𝐢𝐜𝐫𝐨𝐬𝐞𝐫𝐯𝐢𝐜𝐞 𝐃𝐞𝐬𝐢𝐠𝐧 𝐏𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞𝐬

Single Concern Principle:
Having a single concern means that a microservice should do one thing and one thing only . For example, if the microservice is intended to support authentication, it should do authentication only.

This means that its interface should expose only access points that are relevant to authentication. And internally, the microservice should have authentication behavior only. For example, there should be no side behavior such as providing employee contact information in the authentication response.

Interface Segregation Principle:
Each microservice interface should attend to a specific need of a client’s program . In other words, clients should not be forced to depend on an interface they don’t use. One way to implement the principle is through an API gateway.

Loose Coupling Principle (High Cohesion and Low Coupling):
Microservices based applications should have high cohesion and low coupling. The idea behind this concept is that each service should do one thing and do it well, which means that the services should be highly cohesive. These services should also not depend on each other, which means they should have low coupling.

Autonomy Principle:

Microservices should be self contained and operate independently, allowing for easy deployment and management .
Statelessness: Microservices should be designed to be stateless, avoiding the need to store data locally, making them scalable and resilient.

Discrete Boundaries Principle:

A microservice must have clear boundaries separating it from its environment. Another way to think about this principle is that a microservice must be well encapsulated. This means that all logic and data relevant to a microservice’s single concern must be encapsulated into a single deployment unit.
As an example, assume that you have built a web application that enables users to buy shoes online. In that case, you might have one microservice responsible for handling the user s login, and another handling the purchase and billing process.

Event Driven Principle:

Raise and consume Events is a way to accomplish low Coupling and Gain asynchrony.
There are several ways that you can implement inter service communication in microservices architecture. One solution is to use an event based approach where one service publishes an event that another service can subscribe to and react accordingly. Another option is to use a messaging protocol such as HTTP or AMQP so that messages can be exchanged between services without requiring any knowledge about their
implementation details.

Linkdin:

https://www.linkedin.com/in/alirezafarokhi/