Microservices are a popular architectural style that allows for the development and deployment of independent, modular components within a larger system.
While the SOLID principles (Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion) are often cited as guiding principles for designing microservices, there is a newer set of principles known as IDEALS that is gaining traction in the microservice community.
IDEALS stands for Isolation, De-coupling, Evolvability, Autonomy, Loose coupling, and Scaling. These principles provide a set of guidelines for designing microservices that are focused on achieving flexibility, scalability, and resilience in distributed systems.
For object-oriented design we follow the SOLID principles. For microservice design we follow the “IDEALS”.
IDEALS
Interface segregation tells us that different types of clients (e.g., mobile apps, web apps, CLI programs) should be able to interact with services through the contract that best suits their needs.
Deployability (is on you) acknowledges that in the microservice era, which is also the DevOps era, there are critical design decisions and technology choices developers need to make regarding packaging, deploying and running microservices.
Event-driven suggests that whenever possible we should model our services to be activated by an asynchronous message or event instead of a synchronous call. Availability over consistency reminds us that more often end users value the availability of the system over strong data consistency, and they’re okay with eventual consistency.
Loose-coupling remains an important design concern in the case of microservices, with respect to afferent (incoming) and efferent (outgoing) coupling.
Single responsibility is the idea that enables modeling microservices that are not too large or too slim because they contain the right amount of cohesive functionality.
SOLID
Single responsibility complecting responsibilities leads to rigid and/or fragile design.
Open for extension, closed for modification complecting concretions of an abstraction in such a way that new concretions adversely affect existing, working concretions is problemmatic.
Liskov substitution reuse via inheritance is dangerous. It often complects entities not in a true “is-a” relationship, which leads to non-substitutability.
Interface segregation don’t complect clients with uninteresting operations by complecting unrelated groups of operations in a single entity!
Dependency Inversion transitive dependency leads to transitive complectedness!
In summary, the SOLID principles provide a set of guidelines for designing object-oriented software that are focused on achieving flexibility, scalability, and maintainability. These principles can be particularly useful for designing microservices, as they help to ensure that each microservice is focused, easy to understand, and independent, leading to a more robust and efficient system.
Follow me on Twitter for the upcoming updates @dominguezdaniel
Oldest comments (0)