Clean Architecture and SOLID Cheat Sheets

- Blog
- Software-Architecture
November 1, 2020 |
3 min read

Good architectures allow major architectural decisions to be deferred. The job of an architect is not to make decisions, the job of an architect is to defer decisions as long as possible to allow the program to be built in the absence of decisions, so that decisions can be made later with the most possible information.

— Robert C Martin, The Principles of Clean Architecture, Norwich UK, 2015

Sources from Uncle Bob

SOLID Design Principles

SRP: Single Responsibility Principle

Does not necessarily mean that a module should do just one thing, but that a module should have only one reason to change.

OCP: Open-Closed Principle

A module's behavior can be modified without modifying the core code; class inheritance and composition. For example: to swap out a DB implementation, the business logic should not need to be modified.

LSP: Liskov Substitution Principle

Concrete implementations must adhere to the expected interface contracts.

ISP: Interface Segregation Principle

Keep interfaces small!

DIP: Dependency Inversion Principle

Interface abstractions are more stable (change less frequently) than concrete implementations
Use the factory pattern to keep concrete implementations out of business logic
Use a small number of concrete "main" components, where all DIP violations are gathered

Architecture

The goal of software architecture is to minimize the human resources required to build and maintain the required system.

— Robert C Martin, Clean Architecture: A Craftsman's Guide to Software Structure and Design

Two words "soft" and "ware" mean an easily changeable product.

The "policy" (i.e. business logic) is essential; the "details" (e.g. I/O, frameworks, protocols, etc) are irrelevant to it.

Defer architectural decisions as long as you can, so you have the most information possible. For example, wait to choose a DB technology and web framework until the core business app is built.

A good architecture maximizes the number of decisions not made. And you achieve that by using a plugin model.

— Robert C Martin, The Principles of Clean Architecture, Norwich UK, 2015

Dependency Inversion

UI, frameworks, persistence/database, etc depend on the business logic (not the other way around).
Only inject some strategies and factories, keep it limited.
Do not inject your business logic directly into the app. Instead, inject into a plugin abstraction, then the plugin distributes objects. This is so business logic and its tests do not need to know about injection framework.
Do not couple your app to the framework, keep it at arms length.

Business Logic at a Glance: Source Code Structure

Someone new looking at the code should primarily see the business logic; the technical implementation details should be hidden away.

Primary focus of structure should be to describe the business domain
Implementation details should be low-level and should take a back-seat to domain logic in source code