Part 3

Personal takeways from "Robert C. Martin - Clean Architecture" Part 3

p58 - "The SOLID principles tell us how to arrange our functions and data structures into classes, and how those classes should be interconnected. (...) The use of word "class" does not imply that these principles are applicable only to object-oriented software."

p59 - "(SRP: The Single Responsability Principle) - The best structure for a software syste, is heavily influenced by the social structure of the organization that uses it so that each software module has one, and only one, reason to change."

p59 - "(OCP: The Open-Closed Principle) - The gist is that for software systems to be easy to change, they must be designed to allow the behaviour of those systems to be changed by adding new code, rather than changing existing code."

p59 - "(LSP: Liskov Substituition Principle) - (...) this principle says thast to build software systems from interchageable parts, those parts must adhere to a contract that allows those parts to be substituted one for another."

p59 - "(ISP: The Interface Segregation Principle) - This principle advises software designers to avoid depending on things that they don't use."

p59 - "(DIP: The Dependency Inversion Principle) - The code that implements high-level policy should not depend on the code that implements low-level details. Rather, details should depend on policies."

SRP: The Single Responsability Principle

p62 - "A module should have one, and only one, reason to change."

p62 - "A module should be responsible to one, and only one, user or stakeholder."

p62 - "A module should be responsible to one, and only one, actor."

p65 - "The SRP says to separate the code that different actors depend on."

p65 - "The SRP says to separate code that supports different actors."

OCP: The Open-Closed Principle

p70 - "A software artifact should be open for extension but closed for modification."

p74 - "Achitects separate functionality based on how, why, and when it changes, and then orgnize that separated functionality into a hierarchy of components. Higher-level components is that hierarchy are protected from the changes made to lower-level components."

p75 - "The OCP is one of the driving forces behind the architecture of systems. The goal is to make the system easy to extend without incurring a high impact of change. This goal is accomplished by partitioning the system into components, and arranging those components into a dependency hierarchy that protects higher-level components from changes in lower-level components."

DIP: The Dependency Inversion Principle

p87 - "The Dependency Inversion Principle (DIP) tells us that the most flexible systems are those in which source code dependencies refer only to abstractions, not to concretions."

p88 - "It is the volatile concrete elements of our systems that we want to avoid depending on. Those are modules that we are actively developing, and that are undergoing frequent change."