Architecture is the highest level of abstraction that models a software system. The architecture is composed from modules, which are composed of objects, which are composed of functions. Design is applied to each of these layers, and when executed successfully results in a system that is easy to build and maintain. Clean architecture discusses designs at a high level, which like architecture is highly useful. On the topic of architecture, the software industry’s use of the word architect is confusing. The construction analog of a “software architect” is a “structural engineer” and the software equivalent of a “construction architect” is a product manager.
- [User Behavior and Malleability](#user-behavior-and-malleability)
- [Software Paradigms](#software-paradigms)
- II.Object Oriented design principles
- 7. srp: the single responsibility principle
- 8. ocp: the open-closed principle
- 9. lsp: the liskov substitution principle
- 10. isp: the interface segregation principle
- 11. dip: the dependency inversion principle
- IV Component principles
- 12. components
- 13. component cohesion
- 14. component coupling
- Architecture Principles
- 15. what is architecture?
- 16. independence
- 17. boundaries: drawing lines
- 18. boundary anatomy
- 19. policy and level
- 20. business rules
- 21. screaming architecture
- 22. the clean architecture
- 23. presenters and humble objects
- 24. partial boundaries
- 25. layers and boundaries
- 26. the main component
- 27. services: great and small
- 28. the test boundary
- 29. clean embedded architecture
- Videtails
- 30. the database is a detail
- 31. the web is a detail
- 32. frameworks are details
- 33. case study: video sales
- 34. the missing chapter
- Viiappendix
- Aarchitecture archaeology
- Stuff that didn’t fit nicely elsewhere:
See notes on design and architecture
II.Object Oriented design principles
7. srp: the single responsibility principle
Symptom 1: accidental duplication
Symptom 2: merges
Solutions
Conclusion
8. ocp: the open-closed principle
A thought experiment
Directional control
Information hiding
Conclusion
9. lsp: the liskov substitution principle
Guiding the use of inheritance
The square/rectangle problem
Lsp and architecture
Example lsp violation
Conclusion
10. isp: the interface segregation principle
Isp and language
Isp and architecture
Conclusion
11. dip: the dependency inversion principle
Stable abstractions
Factories
Concrete components
Conclusion
IV Component principles
12. components
A brief history of components
Relocatability
Linkers
Conclusion
13. component cohesion
The reuse/release equivalence principle
The common closure principle
Similarity with srp
The common reuse principle
Relation to isp
The tension diagram for component cohesion
Conclusion
14. component coupling
The acyclic dependencies principle
The weekly build
Eliminating dependency cycles
The effect of a cycle in the component dependency graph
Breaking the cycle
The ‘jitters’
Top-down design
The stable dependencies principle
Stability
Stability metrics
Not all components should be stable
Abstract components
The stable abstractions principle
Where do we put the high-level policy?
Introducing the stable abstractions principle
Measuring abstraction
The main sequence
The zone of pain
The zone of uselessness
Avoiding the zones of exclusion
Distance from the main sequence
Conclusion
Architecture Principles
15. what is architecture?
Development
Deployment
Operation
Maintenance
Keeping options open
Device independence
Junk mail
Physical addressing
Conclusion
16. independence
Use cases
Operation
Development
Deployment
Leaving options open
Decoupling layers
Decoupling use cases
Decoupling mode
Independent develop-ability
Independent deployability
Duplication
Decoupling modes (again)
Conclusion
17. boundaries: drawing lines
A couple of sad stories
Fitnesse
Which lines do you draw, and when do you draw them?
What about input and output?
Plugin architecture
The plugin argument
Conclusion
18. boundary anatomy
Boundary crossing
The dreaded monolith
Deployment components
Threads
Local processes
Services
Conclusion
19. policy and level
Level
Conclusion
20. business rules
Entities
Use cases
Request and response models
Conclusion
21. screaming architecture
The theme of an architecture
The purpose of an architecture
But what about the web?
Frameworks are tools, not ways of life
Testable architectures
Conclusion
22. the clean architecture
The dependency rule
Entities
Use cases
Interface adapters
Frameworks and drivers
Only four circles?
Crossing boundaries
Which data crosses the boundaries
A typical scenario
Conclusion
23. presenters and humble objects
The humble object pattern
Presenters and views
Testing and architecture
Database gateways
Data mappers
Service listeners
Conclusion
24. partial boundaries
Skip the last step
One-dimensional boundaries
Facades
Conclusion
25. layers and boundaries
Hunt the wumpus
Clean architecture?
Crossing the streams
Splitting the streams
Conclusion
26. the main component
The ultimate detail
Conclusion
27. services: great and small
Service architecture?
Service benefits?
The decoupling fallacy
The fallacy of independent development and deployment
The kitty problem
Objects to the rescue
Component-based services
Cross-cutting concerns
Conclusion
28. the test boundary
Tests as system components
Design for testability
The testing api
Structural coupling
Security
Conclusion
29. clean embedded architecture
App-titude test
The target-hardware bottleneck
A clean embedded architecture is a testable embedded architecture
Layers
The hardware is a detail
Don’t reveal hardware details to the user of the hal
The processor is a detail
The operating system is a detail
Programming to interfaces and substitutability
Dry conditional compilation directives
Conclusion
Videtails
30. the database is a detail
Relational databases
Why are database systems so prevalent?
What if there were no disk?
Details
But what about performance?
Anecdote
Conclusion
31. the web is a detail
The endless pendulum
The upshot
Conclusion
32. frameworks are details
Framework authors
Asymmetric marriage
The risks
The solution
I now pronounce you …
Conclusion
33. case study: video sales
The product
Use case analysis
Component architecture
Dependency management
Conclusion
34. the missing chapter
Package by layer
Package by feature
Ports and adapters
Package by component
The devil is in the implementation details
Organization versus encapsulation
Other decoupling modes
Conclusion: the missing advice
Viiappendix
Aarchitecture archaeology
Union accounting system
Laser trim
Aluminum die-cast monitoring
4-tel
The service area computer
Dispatch determination
Architecture
The grand redesign in the sky
Europe
Sac conclusion
C language
C
Boss
Pccu
The schedule trap
Dlu/dru
Architecture
Vrs
The name
Architecture
Vrs conclusion
The electronic receptionist
Er demise
Craft dispatch system
Clear communications
The setup
Uncle bob
The phone call
Rose
The debates continued
… by any other name
Architects registry exam
Conclusion
Stuff that didn’t fit nicely elsewhere:
Notice that software is like physical laws in that they can not be proven, but can be falsified. Thus, tests can’t prove software is correct, they can only prove it is broken. The best approximation of correctness is failing to prove software is broken.