Clean Architecture works best when all programmers share the same mindset, or at the very least understand and apply its mindset.
We are uncovering better ways of writing code and architecting software by doing it and helping others do it. Through this work we have come to value:
Expressing the domain simply over expressing the domain via tools and frameworks
Executable documentation over non-executable documentation
Customer usage, deferring technology choices over fitting customer usage into technology choices
Delivering value with low cost of change over delivering hard to change value sooner
That is, while there is value in the items on the right, we value the items on the left more.
- Code rots and becomes a big ball of mud when programmers fear changing code
- Applying a sound strategy for preventing the introduction of defects, such as TDD, unpins eliminating fear. (semantic stability)
- Refactoring can occur at any time when there is no fear
- When the team understanding of the domain improves, keeping the in-code model of the domain up to date is important.
- The SOLID and package principles provide a guide to aid good software design