DEV Community

Cover image for SOLID Principles of Software Architectures
Pramuda Liyanage
Pramuda Liyanage

Posted on

SOLID Principles of Software Architectures

SOLID design principles are five software design principles that enable you to write effective object-oriented code.
The SOLID name is a mnemonic acronym where each letter represents a software design principle, as follows:

01) S for Single Responsibility Principle
02) O for Open/Closed Principle
03) L for Liskov Substitution Principle
04) I for Interface Segregation Principle
05) D for Dependency Inversion Principle

The five principles overlap here and there, and programmers use them broadly. SOLID principles lead to more flexible and stable software architecture that’s easier to maintain and extend, and less likely to break.

Let's us consider each of the principles

Single Responsibility Principle ==>

Each of the services in the microservices architecture should be designed to adhere to a single objective. Simply put, they should have a unique responsibility and be the sole reason behind the change.

Open/Closed Principle ==>

It should be easy to expand the functionality of independent software modules. That is, the expandability of a specific service should not impact the original behavior of the software.

Liskov Substitution Principle ==>

Any two independent services should be able to communicate with each other whenever required through an API call. Also, two services having the same contract should be able to act as a substitute between each other, without altering the overall system.

Interface Segregation Principle ==>

The software should be divided into microservices in a way that there are no redundancies present. That is, the smaller modules should be loosely coupled to satisfy the client’s needs, along with minimizing the anti-patterns present in the code.

Dependency Inversion Principle ==>

The high-levels modules should not be depending on low-lower-level modules. Instead, they both should lean on abstractions. Following the same principle, abstractions should rely on details, while the vice-versa holds true. This principle ensures that changes to the higher-level modules will not affect the lower-level modules.

Thank you..........

Top comments (1)

pramudaliyanage profile image
Pramuda Liyanage

I give you permission