Daniel Orner published a recent article arguing that SOLID principles are still the foundation for modern software architecture. According to Orner, while the practice of software development has changed in the past 20 years, SOLID principles are still the basis of good design. The author explains how they also apply to functional programming and microservices architecture, with examples.
SOLID is a mnemonic and acronym for five software design principles enumerated in 2000 by Robert C. Martin. According to the article’s author, these "SOLID principles are a time-tested rubric for creating good software" and can be adapted to modern software engineering practices.
The author points out some relevant developments in the software industry since the creation of the SOLID principles. Dynamically-typed languages and paradigms such as functional programming or metaprogramming have gained traction and are a common sight in software today. He adds that microservices and software-as-a-service made the monolithic deployment pattern less common and states that many principles governed by SOLID are no longer commonly used by as many programmers as before.
Other aspects of software design have not changed, the author says. People continue to write and modify code, it still is organised into modules, and there is still a need to define its visibility according to its intended user base.
The author proposes to reword the original SOLID principle definitions so that they become applicable to object-oriented (OOP), functional (FP), or multi-paradigm programming and, sometimes, to microservices-based systems.
The author restates the single responsibility principle as "each module should do one thing and do it well". Besides OOP, the new definition is also applicable to functional programming and microservice design.
The open-closed principle becomes "you should be able to use and add to a module without rewriting it". It is accomplished in FP by using "hook points" and is a natural characteristic of OOP.
The author defines the Liskov substitution principle as "you should be able to substitute one thing for another if those things are declared to behave the same way". It now applies too to dynamic programming languages with the help of duck typing or filter functions.
As redefined by the author, the interface segregation principle becomes "don’t show your clients more than they need to see". In other words, only document what your client needs to know. This definition is also applicable to microservices through separate deployments or separate documentation sets.
The definition of the dependency inversion principle remains the same: "depend upon abstractions, not concretions". The author believes that abstraction is still an essential concept, applying to OOP, FP, and even microservices (using message passing instead of direct communication).
Other authors have different perspectives regarding microservices. Paulo Merson argues that SOLID principles are good for OOP but do not fully apply to microservices. Therefore, Merson proposes a different set of principles for microservice design: IDEALS. These are: interface segregation, deployability, event-driven, availability over consistency, loose-coupling, and single responsibility.