Clean Architecture
summary
Argues that frameworks, the web and the database are I/O devices that must be hidden behind architectural boundaries so business rules stay independent; prescribes interactors and entities with input/output boundaries, presenters that produce view models, and all source-code dependencies pointing inward. Shows a concrete story: built Fitness (a wiki/acceptance tool) over a year mostly using in-memory and flat files and only later added MySQL because a customer demanded it — it worked and proved you can defer DB decisions. Emphasizes testable request/response interactors and putting ORMs below the black line.
AI-written summary · about
chapters (7)
- 0:00Introduction and welcome
- 1:46Architecture of the lost years
- 22:46Jacobson’s use cases and interactors
- 36:16Wedding cake architecture diagram
- 49:14Deferring architectural decisions
- 53:26Good code vs rushing in software
- 1:00:14Performance optimization and Q&A
related talks
52mEvolving a Pragmatic, Clean Architecture A Craftsman's Guide
51mA Clean, Pragmatic Architecture
21mTestable Architecture: Keep 'em Separated
50mClean Architecture with Spring
48mIT Architecture : All your micro-services are wrong PERIOD!
50mTowards an Evolutionary Architecture
38mAgile Architecture
49mGetting a handle on software architecture